Fork me on GitHub
Lennart Buit14:01:19

If I have an entity with a composite tuple containing a ref to some ident (‘enum style’), say, I have a person entity for which name + gender are unique. Is it intended that I can’t pull entities by [name, gender] when gender is still an ident? (ex in thread)

Lennart Buit14:01:40

;; Pull with ident
(d/pull (d/db conn) '[*] [:person/name+gender ["Lennart" :gender/male]])
=> #:db{:id nil}

;; Resolve ident first
(:db/id (d/pull (d/db conn) '[*] :gender/male))
=> 17592186045417

;; Pull with eid of ident
(d/pull (d/db conn) '[*] [:person/name+gender ["Lennart" 17592186045417]])
{:db/id 17592186045421,
 :person/name "Lennart",
 :person/gender #:db{:id 17592186045417},
 :person/name+gender ["Lennart" 17592186045417]}

Lennart Buit14:01:19

(Also, majorly bad example, don’t assume name + gender are unique, but you know, example :’) )


Yes, datomic does not attempt to resolve anything in the “value” slot of a lookup ref. You must provide exactly the value that would be found in the datom’s :v, which for refs is the entity id

👍 3

At least, that’s the way it behaves now. It seems conceivable that it could act differently.


Rigidity arises in systems to the extent that the schema pervades the storage representation or application access patterns, making changes to your tables or documents difficult.


Is this referring to be able to do row-shaped, column-shaped, graph-like, and document-like data modeling more freely with less constraints?