This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-09
Channels
- # announcements (19)
- # babashka (26)
- # beginners (157)
- # calva (54)
- # cider (12)
- # clj-kondo (18)
- # cljdoc (3)
- # clojure (65)
- # clojure-australia (3)
- # clojure-europe (28)
- # clojure-germany (14)
- # clojure-greece (1)
- # clojure-italy (8)
- # clojure-nl (10)
- # clojure-uk (81)
- # clojuredesign-podcast (2)
- # clojurescript (20)
- # clr (1)
- # conjure (1)
- # cursive (1)
- # data-science (29)
- # datascript (2)
- # datomic (19)
- # depstar (4)
- # fulcro (24)
- # graalvm (6)
- # helix (26)
- # jobs (2)
- # jobs-discuss (2)
- # kaocha (12)
- # leiningen (1)
- # malli (17)
- # off-topic (18)
- # pathom (34)
- # polylith (23)
- # re-frame (10)
- # reagent (8)
- # releases (1)
- # remote-jobs (1)
- # reveal (5)
- # shadow-cljs (49)
- # spacemacs (1)
- # startup-in-a-month (6)
- # vim (4)
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]]
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)
try thisor 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
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
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!
Should I file an issue?
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
)?