@kenny there is a "feature request" here (please vote!) https://receptive.io/app/#/case/17714

Quick question, would changing an attribute's schema from unique-value to unique-identity be breaking or have any unintended consequences in any way?

@madstap https://docs.datomic.com/on-prem/schema.html#altering-avet-index

If you had :db/index true on the same attribute and you kept your values unique it shouldn’t have much change

however if you did not have db/index set you’re going to keep an AVET index after the change

and there are some other notes in that section of the docs if your values aren’t truly unique

Right, so since it was :db/unique :db.unique/value, that means that there was an AVET index and the change won't break anything. Thanks!

would y’all say nil-punning with boolean attributes is usually a poor modeling choice for flags, since it forces queries to search with (or [?e :attr false] [(missing? $ ?e :attr)])? The alternative being to always ensure that entities that can have that attribute do have it. (I personally prefer modeling flags with enums, but assuming the choice has already been made to use a boolean flag.)

lol a colleague just pointed out that I could use (not [?e :flag true]), so it doesn’t really add any additional work to the query, I suppose

@uwo my opinion: I like to infer things from the presence of attributes. You could also use not, but I’m OK writing the occasional query like the or .. missing example you provide, but say I have entities that have possible statuses processed and not-processed — I would model something like :status/to-process and query for that if I expected to mostly write queries that looks for things to process. Then retract :status/to-process e.g. when the entity was processed. If there are multiple stages though (not binary), I enumerate all the possibilities and basically state-machine it out. In practice for me thus far the perf aspect of realizing an additional set for negation or whatnot has only been an issue with relations between entities (where e.g. relation b/t entities is M * N instead of linear), not with queries just doing the single attr.

I believe (not [?e :flag true]) requires the :flag attribute to exist (haven't tried it though).

Nevermind, that does seem to work.