This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-27
Channels
- # aleph (3)
- # beginners (89)
- # boot (198)
- # cbus (4)
- # cider (11)
- # clara (2)
- # cljs-dev (27)
- # cljsrn (4)
- # clojure (141)
- # clojure-austin (4)
- # clojure-italy (11)
- # clojure-nl (1)
- # clojure-poland (2)
- # clojure-russia (35)
- # clojure-spec (33)
- # clojure-uk (55)
- # clojurescript (111)
- # core-logic (15)
- # cursive (2)
- # datascript (47)
- # datomic (132)
- # emacs (4)
- # jobs (1)
- # lein-figwheel (13)
- # leiningen (15)
- # lumo (20)
- # off-topic (110)
- # om (8)
- # onyx (20)
- # parinfer (2)
- # protorepl (1)
- # re-frame (36)
- # reagent (5)
- # remote-jobs (1)
- # ring (2)
- # ring-swagger (5)
- # specter (6)
- # uncomplicate (3)
- # unrepl (77)
@tonsky i just used datascript in clj for the first time today
glad it exists! š
i used it with joplin to migrate some eavt data stored in another db
Yeah, it's cool... I'm busy writing a datascript based 'database' to use server-side. (https://gitlab.com/kurtosys/lib/factoidic)
Well... the use case is: small applications that can't afford Datomic - the license is only 1 year, unless the free version, but that one requires a peer and transactor. For many applications, it's not necessary.
It'll not be in-memory, btw.
It'll have durable storage.
I'd prefer to use Datomic, but their licensing and pricing model is, in the use case I describe, not sustainable.
or: much easier r to set-up, free and embedded.
@U0E0XL064 I can relate to this. Iām currently on the way to use Datomic in a small, non-profit application. Will your API be compatible with Datomicās API? (e.g. to allow smooth transition)
yes... it'll use the Datascript engine
Which is pretty much the same as Datomic.
I'm checking performance now - it's not really bad.
and yes, small non-profits is where I'm aiming at, they don't need millions of writes per minute etc š.
First trial: writing about 15000-20000 datoms/s right now, which is not bad at all. Will need more tests, though.
@U0E0XL064 good enough for small-medium apps
@U5ZAJ15P0 yeah, well, writes shouldn't be the problem. Not that many systems do 1000s of writes/s. I have to check on the reads - but a lot will depend on the query (and how the user optimizes them). Read performance should be the same as datascript read (query, pull, ...) performance. I will try on a not-so-small synthetic dataset.
adding more datoms/transaction increases throughput a lot (roughly: # datoms x4 -> throughput x2). Batching could be a good idea in very high throughput systems.
Out of curiosity, is Datomicās technology patented in any way? e.g. could one get into trouble for building a ācompetingā system that uses the exact same concepts and API?
don't think so... I mean, I don't copy the same thing: it's a datascript engine + durability of all transactions. There are no peers and many other features that are there in Datomic.
Moreover, it may make the step to datalog much easier... meaning, people my start with a more simple system, and switch to Datomic when necessary.
I just can't switch back to something else... I'm addicted to datalog š.
and I miss the small free embedded thing.
But I'm not copying Datomic's architecture or so.
Anyway... they didn't want to adapt pricing for non-profits, so well, I had to do something š
> ... In terms of pricing, unfortunately we do cannot offer general discounts for Datomic Pro past the initial 12-month trial period. ...
@U0E0XL064 I've read factoidic README. It says factoidic will allow time-travel. Does that mean you are going to save retract datoms to durable storage and modify query engine so that it will take retract datoms into account?
Right, almost: I will store all the transactions. I don't have to change the query engine, all I have to change is to change the database (or database value) the query acts upon. Meaning: if you say: give me the state at time x, it will - not implemented yet - give you the database at time x and you can query that one.
it pretty similar to the way datomic works.
I'm also curious about your approach for durable storage. Will factoidic just copy from durable storage to memory and query against in-memory data, or will it use durable storage's filter (ie SQL where statements) instead?
it will construct an in-memory database (datascript). No SQL-queries.
It's really no rocket-science: it's datomic + append-only durable storage.
I hope I'll have time to finish a first version soon...
@U0E0XL064 btw, I think react native developers can make use of factoidic for mobile apps, so cljc may be the way to go. Of course no pressure, we can add it later š
lol, right š
well, the only thing that has to change is durability.
My first thought was to right to a file, but I replaced that to an embedded H2 db, to avoid opening/closing files etc.
thanks for your work, I'm sure factoidic will be useful for many not-so-big projects
Making durability more pluggable would make it pretty straight forward to implement for browsers, mobile, ...
If you have any ideas or requests, don't hesitate to add them... The pluggable durability is in my head somewhere, but I may have to add it somewhere in the README or wiki or ...