You can think of it that you're not really modifying an existing document, you are adding a new version of the document. Existing documents are immutable.

In Datomic, everything is attribute/value tuples -- no documents -- so you are always adding new attribute/value tuples: it's sort of more obvious that you're not modifying existing attribute/value tuples.

There's also the whole issue of time: valid time and transaction time. So if you think of "modifying" an existing document, which version are you modifying?

If you find yourself repeatedly "modifying" the most recent version of a document, you can use a transaction function to assoc in a new value for one or more keys.

Does that help @UJL94RYSW?

That totally makes sense; the Datomic comparison really clarifies it for me

Coming from a SQL/RDBMS background, it's hard for me to shake off UPDATE table SET column = ? WHERE id = ? 🙂

I guess the preferred method is to query then transact or use the transaction function?

Preferred? Depends what you actually need to do in regards to time-based versions I guess.

I use match operations + retries myself since my app has low traffic, so either approach would be fast enough. I figure if I get scale and start having problems with contention, then I can switch to a tx function. I do it via a helper function, so the document I transact looks like e.g. {:xt/id #uuid "...", :db/merge true, :user/foo "..."}, then the helper fn queries the current version of the doc, adds a match operation to the tx, and retries a few times if the tx fails.

+1 for txn functions for an common doc update patterns. eg we have dissoc, assoc, merge, difference, union