Clojurians Log v2

We have fixed the issue with our docs not working. Big thanks to @audiolabs for fixing everything!

Hello, I have a question regarding recursive pull syntax - is there a syntax for pulling non component entities?

like you implied, component entities pull recursively. for non-component references you can also pull recursively using this syntax: https://docs.datomic.com/cloud/query/query-pull.html#recursive-specifications

Am I blind or is there a bug in the Datalog engine?

(d/q '[:find ?e ?a :in $ ?user :where
         [?e ?a ?user]]
    db my-user-lookup-ref)
  => #{}

(vec (d/datoms db :vaet my-user-lookup-ref))
=>
[#datom[17592186084693 110 17592186072420 13194139573588 true]
 #datom[17592186084696 114 17592186072420 13194139573591 true]
 ...
 #datom[17592186072587 213 17592186072420 13194139561484 true]]

Should I file an issue?

If the attribute cannot be resolved at query “initialization” time, the “v” slot will only match exact matches. It won’t coerce values to an entity id because it doesn’t know that the attribute is a ref until runtime

(d/q '[:find ?e ?a :in $ ?user :where
         [(d/entid $ ?user) ?user-id]
         [?e ?a ?user-id]]
    db my-user-lookup-ref)

or use explicit ?a values visible to the query parser (e.g. with [(ground [:attr1 :attr2]) [?a ...]]

I suspect this is by design for performance, but I’ve never heard cognitect say one way or the other

Thanks @favila

The workaround does the trick, but the behaviour is still quite surprising. If it's not a bug, I think it at least deserves to be documented.

If you’re looking at an :vaet index and don’t know that you want specifically ref :a values, it’s kind of a correctness issue--how will a query engine know it should interpret your V as a lookup ref? Anything you do might be surprising

E.g., suppose there is a literal tuple you want to match, then entid would be wrong

doing both might also be surprising

Is it okay to pass a db created with datomic.client.api/db to a function in the async client api (e.g., datomic.client.api.async/q)?

“Error communicating with HOST localhost on PORT 4334” with fresh datomic pro install. Works on other computers, just not this particular laptop. Anyone seen this before?

SOLVED: we were running the transactor on Java 15

I see your point, but I find it debatable 🙂 from a perspective of logical correctness alone, I could imagine the behaviour being different depending on what attribute is considered. More importantly: your objection is a good point, but not an immediately obvious one. Arguably, the mere fact that we are debating it calls for official clarification.

Anyway, thanks for taking the time!