We’re doing change data capture from our legacy database, and we found ourselves making an assumption that was silly in retrospect. We would construct a tree of txdata to insert, where the root was uniquely identified and thus would upsert, but where the branches were component references. By asserting this as is, we were orphaning the component references. Clearly, we were in a document mindset. Whoops! In order to remedy this, we’re going to try the following: 1. Determine novelty by diffing the txdata prepared for assertion with the corresponding entity in the db and, recursively, its component references. 2. assoc in db/ids to the relevant component refs to ensure upserts I know cardinality many component references will require additional work, but I wanted to run this past y’all to make sure I’m not making a poor design decision or missing something obvious.

@uwo I have a “public” id (a uuid) in all entities, including component entities for this a many other benefits. Also in data layer tests I have a fn which checks the ids persisted against the before and after db and it can report on which ids were inserts. this technique allows me to know exactly when I am (accidentally) adding new entities and it reports on component entities just as well as top level entities

I'm not sure if datomic has an equivalent of select for update. To give an SQL example, let's say you have Accounts table. In one transaction an account wires $100 to 3 other accounts ($30 $20 $50). In SQL what you can do is select for update all 4 rows, calculate the "after-transaction" balances and update all of them. What would the equivalent operation in Datomic look like?

@roklenarcic if you want to do the select and write with no other txns in the middle then a transactor fn is the way to go. https://docs.datomic.com/on-prem/database-functions.html I’m not sure if they are available in Cloud (yet). you can also look into :db.fn/cas

thanks