This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-08
Channels
- # announcements (2)
- # beginners (75)
- # cider (2)
- # clj-kondo (8)
- # cljs-dev (4)
- # clojure (69)
- # clojure-europe (4)
- # clojure-nl (6)
- # clojure-uk (1)
- # clojurescript (17)
- # clojureverse-ops (1)
- # cursive (7)
- # lsp (7)
- # malli (10)
- # missionary (2)
- # off-topic (16)
- # pathom (4)
- # polylith (5)
- # portkey (1)
- # reitit (4)
- # rewrite-clj (1)
- # shadow-cljs (5)
- # spacemacs (3)
- # specter (3)
- # xtdb (14)
so I can only create one document if no other document has the key already, and this is achieved via :match
using nil as the old value
and for the update, I need to make sure that a record already exists, and replace its values with the new document
[[:crux.tx/match id {:crux.db/id id}]
[:crux.tx/put ...
the snippet above fails probably dye the fact that my updated document has more attrs besides :crux.db/idHi, transaction functions are almost certainly what you want to reach for, yep. You can't match
on certain fields only. You could perhaps consider splitting your document into two documents though, so that you can match on one in its entirety
I just want to make sure that a document with that Id exists, transaction fn should be fine just wanted to make sure 😃
I'm not certain I understand your use-case enough to say this is what you want, but just in case you are looking for a "uniqueness constraint", see https://opencrux.com/community/faq.html#uniqueconstraint
do I need to supply the transaction function everytime I want to use it? or should I register my fx fns on app startup and then call them in my app? Im asking because the examples in the docs define the function in one tx and then uses it on another one?
registering the fns on app startup is usually fine, but there are no hard rules and I can't recommend a "best" strategy. The main advice I have is:
1. don't put
on top of existing functions
2. don't evict functions
if it's the exact same version of the function (i.e. idempotent put
ops) then it's okay, but otherwise I'd advise against it on the grounds that it could get tricky to reason about what's going on (in the absence of proper source control management!)
My take on the match
for updates: I am now select-keys
on the doc I am updating to take the "common keys" only. Then I merge with the keys that can be "updatable". That is my entity/doc for match
.
If you are, like me, using http PUT
you have to grab/update the entire entity anyways (idempotently).
Partially update a document is a good use case though and I hope we'll have support for it at some point (for PATCH
)