@lennart.buit This is local. It should be the on-prem version, but I’m connecting via the datomic api client.
Iirc you can’t use fulltext
from the client api
We're running with datomic on the backend and datascript on the front end. I'd like to just mirror datomic ids on the client side, but datascript uses longs for its ids, which means some datomic ids don't fit. Are there datomic settings that can constrain the id space? (if not I'll just write some transformation glue on the FE)
That was my suspicion, but I couldn't confirm. So I need to convert my application to use the peer server internally?
or I guess "should", not "need"
Datomic also uses longs....
Do you mean doubles? Are you worried about the 52 bit integer representation limit?
That depends on what you’d like to achieve. If your goal is to move to the cloud at some point, you may want to consider sticking with the client API and instead using some other store for your full text needs. Here is a thread on the datomic forums about it: https://forum.datomic.com/t/datomic-fulltext-search-equivalent/874/6
I can’t decide what your architecture should look like, but this is advice I’ve seen before 🙂
ah, yes, I guess it's not strictly datatype I'm worried about, but datascript's id limit of 2147483647
(which seems to be 2^31 -1 )
D/tx->t will give you a 42 bit unique id per entity, which is extremely likely to be < 32 bits u less you have a huge number of entities or transactions. Maybe that’s useful info for some clever encoding scheme
If the segment churn on your db is low, consider keeping a valcache volume around and remounting it for this big query job
hmmm, thank you