Hi everyone, we need to implement an auto-increment attribute, what are good patterns in datomic to do so?

it's not possible to go back and add :db.part/tx metadata to a transaction, correct? realized this when attempting transactions with assertions plus tx metadata in the :db.part/tx partition, and noticing that if the assertion was already true, the tx metadata was not added

so, iiuc: if i want to put tx metadata (aka reified transactions) on a specific existing EAV the V must change. otherwise the assertion is ignored.

@devth you can annotate transactions after the fact; simply use its real id instead of a tempid

ie by querying [_ _ _ this] in datalog

@robert-stuttaford ah, makes sense!

:db.part/tx will always reference the in-flight transaction

literally did this today 🙂 had to yank some scheduled mails, and forgot to document the ad-hoc transaction, so i had to find it and annotate it afterwards

awesome. yeah i was relying on the :db.part/tx referencing in-flight txes bit but hadn't considered looking up the tx-id after the fact

thanks!

if i have: [[?p :user/first-name ?fn][?p :user/last-name ?ln]] and I want to bind the concatenation of ?fn and ?ln to ?name, how would i go about doing that

[[?p :user/first-name ?fn] [?p :user/last-name ?ln] [(clojure.core/str ?fn " " ?ln) ?name]] possibly

woah that's so simple

@kennethkalmer no need to prefix str either

even better

wasn’t sure if clojure.core was available, so thought I’d be safe 🙂

@kennethkalmer yeah I just checked the doc to be sure; I had a doubt too 🙂

howzit everyone, I need to ask some advice on how to save a bunch of derived transactions to Datomic. Some background first: I have this abstraction of a data-set, which has a beginning and end date, and a type. these are prepopulated and saved to Datomic. Then I process a ton of other entities and calculate a bunch of derived entities from different entities. this is all simple and well, but I need to “inject” some additional transactions into the mix based on the transactions I’ve seen pass by already… By means of example, lets say I see the following (abbreviated) transactions pass by: [{:db/id -1 :foo/id 1} {:db/id -2 :foo/id 2} {:db/id -3 :foo/id 1}], I wanna concat onto that list [{:db/id 1 :data-set/ids [n m]} {:db/id 2 :data-set/ids [m]}] (where n & m are other eids). You see, nowhere else are entities 1 or 2 referenced in the transactions, so I’m thinking I’d need a transducer that accumulates the seen references to them and build up the additional transactions to concat onto the list. If I just slot them in directly as I encounter my ref I’ll get an exception of trying to update the same entity twice in one transaction. My list of transactions also needs to be lazy, or I’ll run out of memory. The list ends up in a generic function that batches the transactions. I’ve already played with a simple transducer that simply counts the elements in a list and appends that number to the final results and it seems to work nicely when combined with sequence. Thing is, I just don’t know how to best handle this situation (even battling with some missing vocabulary here). Hope this rambling makes sense

now I’m wondering two things, 1) a reducing function that returns larger outputs than inputs is probably a smell, and 2) if this couldn’t be reworked with core.async to be more fluid

@kennethkalmer I am pretty sure a reduce function which returns a large output than input is not a smell

No idea about the rest though, sorry 😄

think i’ll spend a bit of time wrapping my head around http://docs.datomic.com/best-practices.html#pipeline-transactions and core.async. maybe I can come up with something simpler while hopefully getting some feedback here