published a guide to help get started building Datomic apps: http://vvvvalvalval.github.io/posts/2016-07-24-datomic-web-app-a-practical-guide.html

What's the best practice for handeling concurrent changes to an entity in Datomic? For example, if both user A and user B retrieve entity X with transaction id 1 and then user A changes attribute X1 and user B changes attribute X2 and then user A updates the entity with transaction id 2, followed by user B updates the entity with transaction id 3. If the client, by convenience, wants to send all the attributes for the entity to the transactor, how can we make sure that user B doesn't overwrite user A's changes? Our idea is to pass the transaction id with the entity to the client and back again so that the server can do a diff with that transaction and only update the changed attributes. Is there a better approach?

@teng :db.fn/cas

@teng if you have no automated way of resolving conflicts, there's a transaction function :db.fn/cas (compare-and-set) which would cause one of the updates (in your case B) to fail. To minimize the risk, I suggest you perform of diff

@robert-stuttaford you beat me to it 🙂

Thanks!

If I'm using DynamoDB for storage and a datomic transaction completes, is the data already in DynamoDB or is there a period where it's on local disk? Is it safe to destroy the transactor machine and disk immediately when the transaction completes without losing data?

@bmays @djjolicoeur Because of the caching and local execution of query, nested query and/or sequential query are both good options that don’t pay the same kind of penalty sequential query might pay in a more traditional client/server RDB

@yonatanel When a transaction completes successfully the data are guaranteed to be written to durable storage (whatever your backend is) in the log

@yonatanel if your transactor dies immediately after a transaction completes your data will not be lost.

is there a way to mark a ref as cardinality one in both directions?

@hueyp you always have reverse lookups on any ref: http://docs.datomic.com/pull.html#reverse-lookup

the reverse returns a sequence for a one ref — which makes sense, its one-to-many … just wondering if there is a way in the schema to tell datomic to enforce one-to-one and then the reverse lookup would not be a sequence?

er many-to-one

e.g. right now I do (-> entity :thing/_foo first) all over the place 😜