This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-12-28
Channels
- # beginners (2)
- # calva (8)
- # capetown (1)
- # clojure (28)
- # clojure-europe (6)
- # clojure-norway (82)
- # clojure-sweden (1)
- # clojuredesign-podcast (5)
- # clojurescript (26)
- # core-async (3)
- # cryogen (7)
- # datahike (30)
- # datomic (10)
- # figwheel-main (8)
- # honeysql (8)
- # hyperfiddle (15)
- # jobs-discuss (6)
- # lsp (6)
- # matrix (6)
- # off-topic (12)
- # overtone (1)
- # polylith (6)
- # portal (6)
- # releases (1)
- # shadow-cljs (9)
- # sql (1)
- # xtdb (5)
Hey folks, the following query is extremely slow. I'd expect it to be fast as it's getting all the entities that has ?v
as value, and the attribute's ident. Can be done, just by using vaet
for getting entities and then aevt
for the next.
(d/q '[:find [?e ?ident]
:in $ ?v
:where [?e ?a ?v]
[?a :db/ident ?ident]]
(d/db db/datomic-conn) my-val)
;; Runs for more than half a min on a 9 Gigs db. (Result only contains 10 entries)
Whereas if we use pull expression, we get it pretty fast:
(d/q '[:find ?e (pull ?a [:db/ident])
:in $ ?v
:where [?e ?a ?v]]
(d/db db/datomic-conn) my-val)
Am I missing something here?Because it doesn’t know that ?a is a reference attribute and ?v is a ref it is using aevt not vaet
> Because it doesn’t know that ?a is a reference attribute and ?v is a ref it is using aevt not vaet
Isn't this the known order of conditions in where clauses: [entity attr value txn deleted?]
?
I think I need to read more on the indices, clearly my knowledge is incomplete on this topic. Thanks @U09R86PA4 for the response. I am going to read https://docs.datomic.com/pro/query/indexes.html
:where [?a :db/valueType db.type/ref][?e ?a ?v]
might do what you want, but I wouldn’t trust it to always use vaet without testing. :where [(datomic.api/datoms $ :vaet ?v) [[?e ?a]]]
gives you explicit control
This makes sense. Thanks a lot @U09R86PA4
As a matter of hygiene, we fail deploys that have dependency conflicts with the Ion runtime. These conflicts are nicely reported when pushing a revision, but it’s frustrating to merge a branch with a hidden conflict that can only be exposed on push (we don’t deploy every branch in our CI/CD pipeline). It would be really useful to catch these conflicts without requiring a push (99% of which will never get deployed). Has anybody else bumped into this issue? Any suggestions?