The latter option isn't using history.
In the context of a more event-sourced model the former can make a lot of sense with multiple streams, out-of-sync arrivals, various sources of truth etc. but in this case I think the tx-function approach is totally fine. Especially considering that the scale seems small, and Datomic having single global write transactor. Then again if the scale is small enough reducing on every lookup might not be that expensive either.
That's about what I was thinking. I don't think the scale would be large enough for reducing to be a problem. Especially since the query would filter down to the relevant transactions first.
Q: the on-prem api supported running datalog queries against regular vectors/maps (instead of the db). 1/ where are those samples? 2/ is this also possible using the client/cloud API?
In peer you can supply a vector of vectors. You can’t in client
thanks. I thought that was the case. shame but core.match will work too
background: I need a matching api and I’d like to try using datalog instead of core.match
Is there a way to parameterize the pull expression when used in a query? I.e, something like
{:find [(pull ?item ?pull-fields)] … }
(This example does not work)you can have patterns as :in parameters without the ?
So I can, thank you. So the ?
is magic, I just thought it was a part of the symbol name.