I agree it's a grey area. I wouldn't be too concerned about performance as excision is a seldom thing, but yes I do not know the performance / implementation implications of this suggestion. Are you sure the rule is too simple? Why would the first transaction of an entity's attribute (cardinality-many) have any retractions? It's the equivalent of:
@(d/transact conn [[:db/retract "new-item" :m/many "data-1"]
[:db/retract "new-item" :m/many "data-2"]])
which does not make sense.
Or did I miss something?what I mean is that the retracts may be spread throughout the transaction history after the excision time. You need to know what values used-to-be asserted at moment T, and you need to look for the first retraction or assertion of any of those values forward in time. For cardinality-many, there won’t be just one transaction. You can terminate early if all values are accounted for, not on the first transaction
in the worst-case, a value is never retracted later, so you scan all of time
@jdkida you can use the pull API directly https://docs.datomic.com/on-prem/pull.html (onprem)
https://docs.datomic.com/cloud/tutorial/read.html#pull (cloud)
ahh, i see. eid or (unique-id) work?
or lookup ref
https://docs.datomic.com/on-prem/identity.html#entity-identifiers
it takes an entity identfier
Hi all, newbie question: does Datomic support "ordered" :db/cardinality many attributes? I'd like to store a vector of values, and somehow retrieve the same, ordered vector. The actual use case would be an entity that refers to other entities, but those references do have a defined order. I can't seem to find a way to do this on the data model/schema level. Is this an application/client concern rather, meaning I store data required to reconstruct the order and reorder after retrieval?
Check out Datofu, it has helpers for that IIRC
well, the underlying indexes are always sorted, but that order doesn't necessarily survive in a query.
generally you have to do your own sorting in memory. if there's some arbitrary order (say, tracks on an album) then you need to record those as attributes.
putting it slightly differently, you might transact {:foo/id (uuid "...") :foo/things [19 12 22]}
but that's just a shorthand. it swiftly gets unpacked to a set of entity-attribute-value triples, and the order of your vector is lost. it's just a set to Datomic.
Thanks @braden.shepherdson, that's what I suspected - this is an application level concern then.
If you need control over partially-fetching items in a certain order, use d/index-pull
1👍