Fork me on GitHub

@captaingrover in general, whenever your system’s behavior does not match your expectations, I would recommend the scientific method


@U072WS7PE Yeah, I wound up finding a couple of issues besides the n+1 just by removing different parts of the query and timing the result from the repl. For example, I was joining across attributes that were not :db/id & :db.type/ref. I probably should have know that would be slow but seeing the numbers makes it a lot more real. Good talk! Thank you!


that said, you can also improve your expectations in advance by creating SLAs, by modeling your system, and by generative and simulation testing


in your specific example, testing with simulated load would certainly uncover any n+1 roundtrip problem in a system

Drew Verlee20:02:55

Watching the day of datomic video’s i’m somewhat confused by how were using Ids in the transaction to refer to other entities. here is the code that stuart is referring to:

[{:person/name "bob"}
 {:person/id  "a"
  :person/name "Alice"
  :person/spouse "b"}]
Here i would assume what he is describing is how we can transact the idea that bob is married to alice without yet having an id for bob. i would expect that to look something like:
[{:person/name "bob"
  :db/id "b"}

{:person/name "Alice"
:person/spouse "b"}]


@drewverlee I’m pretty sure you’re correct. Either that’s a typo or datomic is inferring from the fact that there are no other entities in the transaction.


I’ve not tried it, but what you have is what I would do.

Drew Verlee20:02:44

Thanks @potetm. I assuming the schema also says that person/spouse is a ref. Also these docs on creating tempIds seem to indicate that the above (as i wrote it at least) would work:

Drew Verlee21:02:10


(let [schema {:aka {:db/cardinality :db.cardinality/many}}
             conn   (d/create-conn schema)])
a shorthand for {ident {shema-key shema-value}} as opposed to: (schema [{:db/ident :aka, etc…}]