This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-31
Channels
- # announcements (1)
- # aws (4)
- # babashka (40)
- # beginners (89)
- # calva (13)
- # cider (3)
- # clj-kondo (36)
- # cljdoc (16)
- # clojure (74)
- # clojure-boston (1)
- # clojure-dev (7)
- # clojure-europe (30)
- # clojure-new-zealand (1)
- # clojure-nl (17)
- # clojure-uk (5)
- # clojurescript (16)
- # core-async (9)
- # cursive (16)
- # datahike (3)
- # datalog (6)
- # datascript (7)
- # datomic (15)
- # emacs (38)
- # events (2)
- # figwheel-main (3)
- # fulcro (6)
- # google-cloud (18)
- # graalvm (6)
- # gratitude (1)
- # honeysql (1)
- # introduce-yourself (1)
- # jobs (1)
- # leiningen (5)
- # lsp (6)
- # malli (11)
- # meander (2)
- # off-topic (4)
- # re-frame (6)
- # reitit (8)
- # releases (2)
- # remote-jobs (3)
- # reveal (4)
- # shadow-cljs (200)
- # sql (8)
- # tools-deps (16)
what’s the best way to find entities without db.type/ref
relationships? in a graph these could be called orphan nodes.
You could query all ref-type attributes, and construct a query with a missing? clause for all of them I think?
missing?
still needs an e
... this would only tell you what entities don't have an outgoing reference, but I think @U050CJFRU is asking how to find all entities for which there is no incoming reference, across all ref type attributes
Off the top of my head, I think you need to do a full index scan to determine this. Scan through EAVT
and VAET
together. For each E
in EAVT
see if there is a corresponding V
in VAET
on either index, once you get a "hit" you can skip fetching all the intermediate datoms by seeking to e + 1
I solved it this way
(def refs
(into #{}
(comp
(keep (fn [[k v]]
(when (= (:db.type v) :db.type/ref)
k)))
(mapcat (juxt identity sdu/reverse-ref)))
(get-schema)))
(into #{}
(comp (map (comp entity :e))
(remove #(some % refs)))
(datoms :ave :ident))
Are there any resources on implementing the internal “auto-increment” ids or their analogues on Datomic Cloud? I want something handy for e-commerce staff to use, so these aren’t primary ids
Hi Ivan, did you find an answer? We're seeking the same thing here also.
Has anyone implemented or documented how to maintain sequential, auto-increment IDs with Datomic Cloud?
@U0514DPR7 I did this using transaction functions
At your own risk
Combine this https://gist.github.com/favila/f33518c7e72a4079b5948d2f853053b0 And this https://docs.datomic.com/cloud/transactions/transaction-functions.html#creating
Thanks Ivan!
In Datomic cloud, if we change an attribute to noHistory true, will old segments that have old values in them ever be re-written? I have a system I'm working with that was using large strings. They've stopped doing that and retracted them all, but since there is no excision there isn't a real way to compact the old fragmentation as far as I know...wondering if the noHistory flag will help at all? I think that the segments are immutable, so I kind of doubt that it's going to fix "fat segments" that have large strings....but anyway, just fishing for possible things that might help
if it’s anything like on-prem, noHistory will not proactively remove history for that attr, merely omit it from future segments that happen to involve it.
Has anyone implemented or documented how to maintain sequential, auto-increment IDs with Datomic Cloud?