I am not part of the Crux team but the Datomic/Datascript way would be to use an attribute that you know is uniquely identifying your entity as :db/id

There is actually way more at this page: https://docs.datomic.com/cloud/whatis/data-model.html#identity-and-uniqueness

Crux expects :crux.db/id to be a globally unique key. One option is generating a random UUID. The advantage of providing a UUID to the database is that you can create the UUID where you first want to "track" your entity from. If you create that UUID on the frontend, will later be able to query for exactly the entity you created. To me, a random UUID seems like a robust default choice, unless you have specifc conflicting requirements.

Maybe this discussion can help: https://clojurians-log.clojureverse.org/crux/2020-02-11

Is there an important distinction to make here between a "persistent" entity (I know "persistent" is really overloaded here but not sure what else to say) and a "transient" entity?

For example, let's say we're implementing the Slack server with Crux, and I want to model Users and Messages. I can imagine some uniquely-identifying information about a User (username, or email address might do) but I can also imagine where using domain information as the ID could get me into trouble. (A user wants to retain their identity but edit their username or switch to a new email address.) However I can't imagine a simple way to identify a Message with domain information, so the only good option there seems like a random UUID.

The fact that a crux client can pre-determine the ID is a nice feature if you want to asynchronously submit the tx, not wait around for confirmation that the tx was successful, but still have a way to precisely refer to the entities that may have been created. However, it's surprising to me that I'd be required to specify a unique ID with every submitted entity. It seems brittle to require that all clients correctly adhere to the unique ID constraint for every tx they submit and never make a mistake. Are there any patterns for standardizing this process? The first think I could think of is to wrap crux.api/submit-tx with a function that merges in {:crux.db/id (UUID/randomUUID)} for any entity that wasn't given an ID.

Hi 🙂 in the context of Crux, an ID is a :crux.db/id value. Every distinction, model or usage pattern beyond that is, for the time being, an opportunity for collective experimentation and experience reports. For instance, your wrapper function seems like a reasonable default, but it could possibly discourage users from thinking hard enough upfront about how to map their domain model. I may well be wrong! This is useful feedback though, and certainly we will try to do more to document and assess these patterns as they're spotted.

My general feeling is I prefer to keep the implementation of unique identifiers separate from the domain model for the reason listed above (changing username/email). This approach decomplects uniqueness of domain data (e.g. only one user account allowed per email address) from tracking identity of an entity over time (one user account can change email address over time). So I'd be perfectly happy if submit-tx generated and returned UUIDv4s for all my :crux.tx/puts, as one possible API.

I'd be interested to hear what kind of approaches you've seen in use either in your own projects or in community projects, and what pros and cons each approach might run into. I tried to get started with Crux a few months ago and I remember running into this same data modeling question, so I imagine it could be a barrier to entry that would greatly benefit from some opinionated guidance in a blog post or section of the docs.

Thanks for all your work on this, and I appreciate the access to conversations like this one.