Hey @U4Z9Z95HQ - :crux.db/id is inherently unique and you should be able to break your data model apart to rely on this. For instance, these two documents together: {:crux.db/id :unique-val-123 :unique-val/owner :someid} {:crux.db/id :some-id :non-unique-attribute 456} capture that a certain att+val combination (`:unique-val/owner` :unique-val-123) associated with a given entity (`:some-id`) must be unique. Essentially the inverse of the reference attribute that you would intuitively model. Can you describe more about the kind of uniqueness constraint you are hoping to capture?

Hi @U899JBRPF, thanks for your response. I'm creating a user sign-up flow in which I would rather not use the user's email as the id of the document representing them, but would still like the email address to be unique.

okay so yes in that case I would create a transformation of the email into something that can be used as an ID, then have that as a distinct entity which points to the unique user with which it is associated with

so one easy solution would be to append "mailto:" and use the URI id type e.g. `{:crux.db/id #crux/id "<mailto:[email protected]>" :email/owner :some-user}`

Hmm, interesting, thanks!

In terms of the constraint then, I would use a cas transaction to insert the email with 'nil' as the expected document ?

yep, that's the trick 🙂

Great, thanks for your help!

No problem - thanks for asking - it's a good idea for inclusion in a tutorial or an entry in the docs

if you don't want the email address at all visible in the key, you might also be able to use one of the hashing UUID versions (3 or 5, if memory serves) - UUIDs are also valid keys in Crux 🙂

yep, 3 uses MD5, 5 uses SHA1

I've used https://github.com/danlentz/clj-uuid in the past, makes generating them much easier

I had thought about using a hash as the id, didn't think of hashing uuid versions, thanks!

Hi, just looking into this a little bit more, I guess the constraint failure of the cas transaction happens in another thread, so I need to wait for the transaction to be processed before I know that the constraint has failed ? This is from the test suite:

(t/testing "can create new user"
    (let [{:crux.tx/keys [tx-time
                          tx-id] :as submitted-tx}
          (api/submit-tx *api* [[:crux.tx/cas nil {:crux.db/id :ivan
                                                   :name "Ivan 1st"}]])]
      (api/await-tx *api* submitted-tx)
      (t/is (true? (api/tx-committed? *api* submitted-tx)))

      (t/is (= #{["Ivan 1st"]} (api/q (api/db *api* tx-time tx-time)
                                      '{:find [n]
                                        :where [[:ivan :name n]]})))

      (t/is (= tx-id (:crux.tx/tx-id (api/entity-tx (api/db *api* tx-time tx-time) :ivan))))

      (t/is (= {:crux.db/id :ivan
                :name "Ivan 1st"} (api/entity (api/db *api* tx-time tx-time) :ivan)))))

crux.bus is currently for internal use I'm afraid - we haven't ruled out exposing it but I wouldn't rely on it just yet there is a Kafka-based async ingest API, which you can start up using crux.api/new-ingest-client - we're considering extending this to other tx-log implementations too in the future (as part of https://github.com/juxt/crux/issues/383)

Wrapping together the existing functions into a submit-then-await-tx-promise API sounds reasonable, and we would be happy to include such a function in the docs or in a utility lib in crux-labs. At the moment we are focussed on lower-level changes so we won't be adding such APIs officially until we have greater stability and a clear window to assess what's most useful & ergonomic. This is would be a good candidate for discussion as part of the upcoming beta though: https://www.opencrux.com/support

Sounds good. I guess the motivation for me is that if I'm using a full-async webserver like aleph, I can wrap the cas transaction in a deferred and chain that as part of a request handler, which is slightly more efficient than blocking the thread. Thanks for your help and thanks for open-sourcing crux!

Ahhh, okay, interesting to know the context. We will take note 🙂 (and you're very welcome!)