Fork me on GitHub
Quentin Le Guennec09:07:51

Hello, am I supposed to be able to resolve this pathom query: [{[:person/email ""] [:person/id]}] if :person/email is a datomic attribute defined with:

   {:db/unique :db.unique/value}

Jakub Holý (HolyJak)08:07:53

That sounds reasonable. If it does not work I would look at the code that generates the resolvers, it is not so hard to read.


I’ve been looking at Fulcro RAD Datomic adapter and I was struck by something I didn’t think of before. In RAD models we have many “identity” attributes like person/id and such and each is basically the core of an “entity” of sorts, by linking together a specific set of attributes like person/name person/email. But the way most of these datalog stores work (Datomic for instance), all entities use same attribute :db/id as the base “identity” and then all attributes are added on that. They also offer secondary identites via attributes with :db/unique :db.unique/identity. The fulcro RAD adapter for datomic, for instance, creates such a secondary identity attribute for each “identity” fulcro attribute. So what am I thinking about is this: Does use of these secondary indexes make the system much slower, due to extra lookups, extra mem and hard drive useage? Would it be a worthwhile project to try to make the code work with :db/id directly?

Jakub Holý (HolyJak)08:07:03

Not sure about the performance impact in practice. Perhaps start by measuring that? You know, premature optimization... I'd expect Datomic to be really good at these lookups. If you are fetching 5 attributes then I guess using a lookup ref like person/id would make it 20% slower due to the extra lookup - or 10% if you are fetching 10 attributes. But does it really matter, compared to the cost of the call from the frontend to the backend, since this is a in-memory lookup of some ± log(n) cost? IMO Tony has tons of experience with Datomic and obviously did not observe this as being any problem. You do not want to have :db/id in your fulcro entities b/c that would conflict with the fundamental assumption that each entity has a unique id prop. You could however add a thin layer renaming :db/id to <entity>/id if you really discover it matters performance-wise.