Fork me on GitHub

@pesterhazy: I currently use (d/pull db [:my-entity/id] 99999) where :my-entity/id is the external id attribute of the entity. Apart from that I find the behavior of seq on the result of d/entity rather funny to stay friendly. (d/entity db 9999) prints as {:db/id 9999} but (seq (d/entity db 9999)) returns nil where (seq {:db/id 9999}) returns ([:db/id 9999]) as expected. I always thought d/entity returns something which behaves like a map (a lazy map).


@akiel, d/pull is a good suggestion


EntityMap does behave a bit funny, but that's a consequence of its laziness I guess


Hi there, having some trouble with lookup refs in in transactions. I want to create a new entity “A” and set a reference to a existing “B” entity “b” via the attribute A/bs. I have b’s unique id (B/id) therefore I write my transaction as:

[{:db/id eid :A/id “new id”}
 {:db/id eid :A/bs [:B/id “b’s id”]}]
But when executing this transaction I always get:
IllegalArgumentExceptionInfo :db.error/not-an-entity Unable to resolve entity: “b’s id” in datom [#db/id[:db.part/user -1000079] :videos/tags #uuid “b’s id”]  datomic.error/arg
Are lookup refs not allowed as values in transactions, or am I using them wrong her? Thanks for any help in advance!


@amp: try using [[:B/id “b’s id”]]


@marshall: 👍 thanks it worked!


@amp: Because you’re permitted to transact multiple values for a card many attrib ( you have to use the extra vector wrap to indicate it’s a lookup ref, not a list of 2 things


okay ... now I understand, thanks for the link

Ben Kamphaus15:02:32

@akiel and @pesterhazy if you can guarantee in your data model that some other id will be on the entity, that approach with pull is a reasonable take. Regarding entity behavior - it’s a combination of the fact that (1) it is lazy (as you mention) and (2) :db/id is not an attr/val specified by any datom (it’s just the entity position that groups the datoms). entity only returns actual attr/val pairs. I don’t really like the seq approach as it’s not particularly evident what’s going on in the code, if you’re married to it I’d change it up to something more clear like (empty? (into {} (d/entity db 999)))

Ben Kamphaus15:02:30

It would make more sense to hear about the use case in which you end up with an entity number and aren’t sure if it’s in the db or not. Assuming as-of or since or history vs. present db filtering (probably the typical case where you’d encounter it), note that if you use a query again e.g. as-of or history originally, it might make sense to pass multiple points in time and modify the original query ( ).


@bkamphaus: Good point about :db/id being no attribute. It’s the same as in transaction maps. :db/id is just syntactic sugar.


@bkamphaus: we get entity ids from untrusted source -- say, passed from APIs -- and need to check if the entity actually exists. For example, d/touch throws a NPE if the entity does not exist

Ben Kamphaus15:02:36

@pesterhazy: ah, I see. I do recommend against doing that to be honest. I would use a separate external key (generating one via squuid if necessary), and use the entity id only when retrieved in datalog or by the API (see )


interesting. didn't know that was recommended


it's a bit tedious to have to have an explicit "primary key" attribute for everything exposed to the api

Ben Kamphaus15:02:18

One primary issue is entity id’s aren’t assignable and therefore can’t be guaranteed stable across migration or sharding strategies.


that is true, we've seen that issue before


you can always use lookup refs [:my/uuid #uuid "..."] wherever you'd use the entity id otherwiese


Are there any docs on why a backup can fail?

Ben Kamphaus20:02:44

@arohner: can you be a little more specific about what you mean by a backup failing?


I’m running bin/datomic -Xmx4g -Xms4g backup-db datomic: file:/Users/arohner…


Copied 5356 segments, skipped 16536 segments.
Copied 5379 segments, skipped 16536 segments.


I’ve done this before, successfully, on this machine


though not in a few weeks

Ben Kamphaus20:02:04

@arohner: anything in the backup process logs? (by default should go to log/ dir of that Datomic directory)


ah, I didn’t know that existed



yeah, ok, I know how to deal with that

Ben Kamphaus20:02:40

Cool, glad it was something obvious! Usually failures to write to disk etc. I believe get reported, if something dies without reporting error to stdout or stderr, logs are the next place to check (for datomic processes in general, sometimes something at WARN or not typically catastrophic FAIL/ERROR/Exception level can still be responsible for failure)