datomic

braai engineer 2025-10-04T07:44:41.597189Z

Encrypted homomorphic search for Lucene: has anyone looked at supporting encrypted search so I can encrypt customer strings but still enable search on those strings that support the bulk of Lucene wildcards, using Datomic Pro? I could tokenize & hash strings & associate those terms with entities, but I really don't want to build my own search engine at this time. Given that customers would have unique public keys, this would break search across tenants, but this is fine for my use-case as DBs are mainly tenant-specific.

robert-stuttaford 2025-10-04T09:16:16.378769Z

what is the recommended method for finding the cause of a 'tempid is the only id used in the transaction' in a very large transaction? i only have the large negative long value from the exception, and of course the transaction with all its d/tempid values. i have already analysed the tx to confirm that all ids in V position are also present somewhere in E position, and found no missing references this way. the tx is huge - 170,000 entities. it's a 'control data subset' export of our prod db for use in test / dev environments. i can't bisect the tx easily because there are of course many relationships between these entities, and cutting it up will introduce lots of broken references. it would be really fantastic if the exception gave me the tempid in the form that i have it 😅

👍 1
favila 2025-10-04T13:14:25.107959Z

Convert your tempids to negative longs in the tx data using entid-at; then they will look the same as the error message

👍 1
favila 2025-10-04T13:15:49.372369Z

See “tempid longs” section here https://favila.github.io/2024-05-16/datomic-entity-id-structure/

robert-stuttaford 2025-10-05T07:58:56.828849Z

amazing gonna try it, thanks!

favila 2025-10-05T12:40:53.254529Z

You could also do the opposite: convert the long into a tempid record

robert-stuttaford 2025-10-06T06:10:49.969749Z

i got it all set up and when i retried the tx ... it succeeded 🤷‍♂️ now i have it in my back pocket for next time, thanks @favila!