+1 for pyry’s suggestion, keeping an index outside of the main Datomic database
Thanks. I worked with Postgres and Elasticsearch and this is the approach we took then too.
I noticed attribute predicates check explicitly retracted values (from user-supplied tx data or tx-fn expansions) but not implicitly retracted values (from cardinality-one attributes with a new assertion). 1) Why check retractions at all? 2) Why this difference? I’m observing this on on-prem 1.0.6165 if it makes a difference.
I would prefer that attribute predicates are never run on retracted values as it makes it much easier to migrate to cleaned-up values. In our case we’re installing string length limits, and would be ok with old values being too long as long as new values are not.
1👍It also means we need some kind of atomic tx fn to install an attribute predicate safely.
might be better to log this at https://ask.datomic.com ...
IMO this is a bug report; I’m just being polite 🙂
:)
standard support channels are best, then ask.datomic as it creates a searchable archived record for the future, and then here is good for conversation but checked less frequently than the above