Hey Crux folks! I was wondering what the design reasoning was behind enforcing that IDs be keywords and not allowing strings? Since Clojure keywords are interned doesn't this mean that a stream ingesting an infinite sequence of data will eventually run out of memory as the keywords for each ID are never released from the runtime?

Hey @rschmukler 🙂 Keywords are just one of the ID types we support - currently we also support UUIDs, URLs and URIs. We're also actively considering how best to support string IDs as part of our upcoming index changes - currently strings are handled differently in the index because of the ability to efficiently range search over them (which the other ID types don't have)

Thanks for the quick reply! That makes a lot of sense. I've currently just been wrapping transactions with something that generically encodes strings to keywords - but supporting range queries would definitely be nice. Similarly, it may be worth considering integer based primary keys which also may have a range aspect. One other thing that I've been doing is allowing for tuples so that I can use other service providers' primary keys as IDs. Eg, if I'm ingesting a tweet I use [:twitter/id 12345] and then I have a function that encodes that into a keyword of :db.id.twitter/12345 - this feels especially weird since that keyword is not syntactically valid (ie. you couldn't write :db.id.twitter/12345 and have clojure pick it up) despite the fact that you can create it with the keyword function

I do definitely think it's useful to retain the compare-based aspects of ID order - eg. Reddit's pagination API uses the order of the IDs with an :after parameter. While that can be re-implemented in Crux elsewhere, I think having it baked into the notion of identity is powerful