Fork me on GitHub
#datomic
<
2021-02-09
>
jaret00:02:26

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

Ben Sless09:02:39

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

joshkh12:02:47

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

val_waeselynck14:02:42

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]]

favila14:02:37

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

favila14:02:41

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

favila14:02:20

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

favila14:02:10

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

val_waeselynck15:02:51

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.

favila15:02:01

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

favila15:02:35

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

favila15:02:52

doing both might also be surprising

val_waeselynck20:02:16

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.

val_waeselynck20:02:50

Anyway, thanks for taking the time!

val_waeselynck14:02:49

Should I file an issue?

kenny18:02:47

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

micah18:02:28

“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?

micah19:02:36

SOLVED: we were running the transactor on Java 15

👀 3