Fork me on GitHub
Vincent Cantin11:01:45

I found a typo on the web site ( "three ways to sepcify an entity id" -> specify


I’ll fix it right now. Thanks for the catch!

Vincent Cantin09:01:59

It is still there.


there's a couple more there


Each list a transaction contains represents either


and, similarly Each map a transaction contains is equivalent to @jaret


Thanks! I’ll fix those as well.


@U8L9BNAJE The wording seems correct to me. I did note that we had a semi colon where we needed a comma though. Here is the original text: >“Each list a transaction contains represents either the addition or retraction of a specific fact about an entity, attribute, and value; or the invocation of a data function, as shown below.”


@jaret on 3rd read, yes, you are correct. Maybe it's the language barrier but my mind was hung-up on reading it like "Each list [in] a transaction" but now I understand it refers to what is above


Maybe 'Each list that is contained by a transaction represents...' is better?


It’s definitely a mouthful. I’ll confirm with the team to see if a rewording, like the one you suggested would work.

Vincent Cantin16:01:30

I am a beginner with the Clojure eco-system, and after fast-reading Datomic's documentation I still have difficulties understanding its position compared to another db-bound framework/data-flow which I am familiar with : Meteor. Here are my questions: 1. Suppose that I want to dev a web-app with reactive data update from the db to the ui, similar to what can be done with Meteor, is Datomic a valid candidate for a replacement? Would something be missing in the reactivity chain between the client and the server-side peer? 2. How/where is handled what part of the data each client is/is-not supposed to see?

Vincent Cantin16:01:39

Now that I think about it, I did not see anywhere a mention about reactivity or pub/sub. Maybe that's not what Datomic was designed for. Sorry if I misunderstood.


Datomic has the capabilities to do this, but isn't particularly specialized for it. Having immutable data is a big enabler of that kind of thing though. If you were to write something like this, you'd probably use the transaction report queue. There's a project aiming to demonstrate this here (I haven't looked at it closely):


You'd still need a web server in there to do the tx-report-queue to websockets transmission, and to do security filtering, etc. That part of the code isn't built in to datomic and you have a lot of options


There is a project called datsys which aims to do a lot of this type of thing, replicating a datomic database into the client and then hooking that up to react. It still seems like early days though.


While we're on the subject of txdata... What could be wrong here: I have this tx: [:db/retract 17592186045418 :myns/myattr #inst "1999-06-23T22:00:00.000-00:00"] but I get: :db.error/invalid-lookup-ref Invalid list form: [:db/retract 17592186045418 :myns/myattr #inst "1999-06-23T22:00:00.000-00:00"]


Is that the entire tx? no outer containing list?


It's not the entire tx


[map-or-tx-fn, map-or-tx-fn, ...] is the format


yeah, a 'list of lists' as it says in the datomic doc


error indicates it thinks your assertion is being used as a lookup ref


so it's either a value in a map or nested too deep in a list


maybe you map somewhere where you should mapcat?


must every retraction be processed in a seperate call to transact?


ok so i'm getting the collection-dimensions wrong somewhere...


no, retractions do not need to be alone


my full tx combines updates and retractions. That is not invalid, correct? (as long as i provide the correct list)


there are no transaction batching restrctions except you can't do conflicting things


but that's not the case here


this is clearly a syntax error


if you pretty-print your transaction (entry per line) it may be easier to see


thnx so far


fixed it, and you were, of course, correct 🙂


Could this be related to the :db/txInstant of my schema?


How are other people managing schema and data changes in their projects? Kinda like database migrations in a relational database.


We wrote a tool that scans the current schema from the database, compares that to our master schema definition (just a bunch of edn), creates a diff between the two, and applies the diff. Overall it wasn’t hard to write.


We generally use which is simple and just makes sure you don’t apply the same block of transactions twice in a give database


We’ve been looking into too, which is somewhat ActiveRecord inspired, apparently