Fork me on GitHub

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?

Adam Lewis15:01:29

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

👀 1
Adam Lewis15:01:56

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

Adam Lewis16:01:06

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 #{}
            (keep (fn [[k v]]
                    (when (= (:db.type v) :db.type/ref)
            (mapcat (juxt identity sdu/reverse-ref)))


  (into #{}
        (comp (map (comp entity :e))
              (remove #(some % refs)))
        (datoms :ave :ident))

Ivan Fedorov17:01:46

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

Daniel Jomphe18:02:59

Hi Ivan, did you find an answer? We're seeking the same thing here also.

Daniel Jomphe18:02:32

Has anyone implemented or documented how to maintain sequential, auto-increment IDs with Datomic Cloud?

Ivan Fedorov13:02:40

@U0514DPR7 I did this using transaction functions

Ivan Fedorov13:02:59

At your own risk


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.