This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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)
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.
I'd prefer to use Datomic, but their licensing and pricing model is, in the use case I describe, not sustainable.
@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)
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.
@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.
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.
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?
@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 🙂
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 ...