d/entity, refs, and :db/ident

[Brandon Bloom]

I noticed some strange behavior (maybe a bug?) at the intersection of
entity ref attributes and :db/ident

The problem is that ref attributes (both cardinality one and many) don't
produce entity objects if the entity has a :db/ident attribute attached. In
that case, the ident itself is returned as a keyword.

For example:

(deref (d/transact conn [{:db/ident :foo/ref
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}]))


(deref (d/transact conn [[:db/add "x" :db/ident :thing]]))


(let [y (-> @(d/transact conn [[:db/add "y" :foo/ref :thing]])
(get-in [:tempids "y"]))]
(-> (d/db conn) (d/entity y) d/touch :foo/ref)) ;=> :thing

This took me by surprise while doing some generic traversals of entities.

Luckily, d/entity-db exists. Combined with the expected behavior of
d/entity, you can work around this problem:

(d/entity (d/entity-db e) :db/doc) ;=> #:db{:id 62}


Is this a bug? If not, is the behavior documented somewhere?

Thanks,
Brandon

[Francis Avila]

It is intentional, but unfortunately I can't find documentation for it in any of the places one would expect it. Perhaps it is only in old tutorials now.

The intention is to naturally represent "enum" values, e.g. the values of the schema attributes. Cognitect seems to have backed away from this use because they say they will never implement it for the pull API even though people ask for it not infrequently.

[Brandon Bloom]

Post by Francis Avila
The intention is to naturally represent "enum" values

Aaaah, OK, that makes some sense.

I wanted to use some keywords for a couple of interesting "root nodes" for
convenience. I guess I have two options:

1) Just make my own unique column and use lookup refs like [:my/attr
"abc"], which is almost as convenient as :abc.
2) Use the d/entity-db & re-query d/entity workaround stated above.

I'll probably use a blend of the two, as I have some interesting root nodes
and I also want to do some generic processing guided extra data attached to
attributes. I'll avoid the enum behavior for these root nodes, but
workaround it for the generic processing.

Thank you,
Brandon

[Dustin Getz]

Relevant docs: http://docs.datomic.com/identity.html

[Dustin Getz]

The pull API doesn't do this; only the entity api.

[Dustin Getz]

It helps to think about how datomic uses idents internally. Statements and
datalog queries use them. Do you see the lookup refs here?

[:db/add -1 :person/name "Brandon"]

[Francis Avila]

Either the entity API docs or the d/entity docstring should mention this, but neither of them do. (These are the places I checked, and even though I know about this behavior I wasn't able to find it documented)

Sent from my iPhone

Post by Dustin Getz
Relevant docs: http://docs.datomic.com/identity.html
--
You received this message because you are subscribed to a topic in the Google Groups "Datomic" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/datomic/QrnijffSAfU/unsubscribe.
For more options, visit https://groups.google.com/d/optout.

[Adam Lewis]

I've hit this myself a couple times, always surprised me. Unfortunately
this detail is effectively baked into the interface, so considered a "won't
fix / not broken".

1) Just make my own unique column and use lookup refs like [:my/attr

Post by Brandon Bloom
"abc"], which is almost as convenient as :abc.

Also note that :my/attr could have value type of :db.type/keyword if you
don't want to use strings here.