xtdb 2021-08-08 | Slack Archive

Im trying to use the :put tx to simulate the classic create/update behaviour

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

plins21:08:10

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/id

plins21:08:50

is there a way of matching on certain fields only?

plins21:08:09

or should I use a transaction fn to fetch the record and check that it exists

refset21:08:13

Hi, 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

plins21:08:47

I just want to make sure that a document with that Id exists, transaction fn should be fine just wanted to make sure 😃

plins21:08:51

thanks for the fast response

🙏 3

refset21:08:01

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

plins21:08:59

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?

refset21:08:35

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

plins21:08:54

so creating the same function twice is a no go?

refset21:08:31

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!)

richiardiandrea15:08:05

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)

2021-08-08

Channels