@eraserhd Curious what you contributed and if there’s support for multiple cardinality in clara-eav.

see https://github.com/eraserhd/clara-eql

This doesn’t some how allow you to have: [42 :attr “a”] [42 :attr “b”] Because you can’t insert both of those correct? I’m not understanding how the multiple cardinality could work.

@eraserhd

you can’t insert both of those indeed, upsert replaces the former with the latter

So then I’m not understanding what this does: Many-valued Attributes The shape of the pull result differs for many-valued attributes. clara-eql assumes these attributes have a fact`(->EAV attr-name :db/cardinality :db.cardinality/many)` I guess the eids actually would have to differ for this to work?

https://github.com/eraserhd/clara-eql/blob/develop/test/net/eraserhead/clara_eql/pull_test.clj

If you use clara insert you can insert multiple eavs with the same :e and :a

Is there a downside to that? This actually solves some data representation issues I was having.

Downside: inserted eavs won't be registered in the store's eav-index, and upsert won't retract them in subsequent calls with replacement values

upsert exists precisely for this reason, to retract eavs that are being replaced

If the EAVs aren’t in the eav-index, is that limiting?

limiting, in the sense that upsert won't retract them in subsequent calls with replacement values

otherwise I see no problem

I see, i think for my use case that’s typically OK as my data will be for the most part immutable.

upsert exists so one can do mutations, if you don't need it great

I can limit upserts to where i need to have some “control flow” in the rules. This is really good.

Is there a way I can use insert yet obtain an eid for it to ensure there is no collision?

I guess UUID would be the expected way.