@tony.kay that's pretty awesome!

"Assumes that the Datomic schema makes use of the :entity/attribute convention for all attributes." -- that's a pretty strong assumption though

it is a strong assumption. as a data point, we have over 600 attrs and they all follow that convention

as another data point, we do use the entity-type/attribute convention, but we sometimes mix-in several entity types for the same entity, i.e {:animal/sound "woof" :dog/breed "labrador"}

so not sure it complies to said constraint

@val_waeselynck are you working at a pet shop?

@pesterhazy not at all, but mentioning attributes we actually use would be leaking IP

sorry was just a joke

(just kidding, really it's just that it seemed more clear)

FWIW, we also use the :entity-type/attr convention

any examples of other conventions?

or is it about entities having :non-entity-type/attrs, like :db/id?

@robert-stuttaford greetings! how do you handle ordinal :db/isComponent false entities? I end up wrapping those in

{:ordinal/idx 2
 :ordinal/ref [:user/email ""]}

one example is cross-cutting attributes, like a created-at attribute

@val_waeselynck the mixed attr case you listed above would be fine as far as the sql-datomic tool is concerned. it is mainly the case where there is no namespace for an attribute that the tool might not take into account.

does the tool use pull syntax or datalog to pull in attributes?

@misha i’m not sure i understand your question

@pesterhazy It grabs the entities with non-pull syntax and then filters out attrs.

it uses d/entity? I see

it's important as for handling of missing attributes (NULL columns)

whats with the negative temp ids?

@afhammad they become positive once transacted