This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-23
Channels
- # announcements (5)
- # aws (9)
- # babashka (60)
- # beginners (561)
- # calva (8)
- # cider (17)
- # clj-kondo (1)
- # cljsrn (12)
- # clojure (36)
- # clojure-dev (3)
- # clojure-europe (3)
- # clojure-france (10)
- # clojure-greece (8)
- # clojure-italy (6)
- # clojure-spec (3)
- # clojure-uk (6)
- # clojurescript (30)
- # community-development (2)
- # conjure (15)
- # datascript (24)
- # figwheel-main (49)
- # fulcro (29)
- # helix (72)
- # off-topic (20)
- # pathom (7)
- # rum (7)
- # shadow-cljs (23)
- # spacemacs (6)
- # sql (8)
- # timbre (1)
- # xtdb (10)
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'm curious about what people are doing for foreign keys / composite keys like this. I guess URI encoding could work?
Coming from datascript, composite keys like [:twitter/id 1234]
smell familiar ...
I can see range searches for IDs being handy - will give it some thought. @U3X7174KS for composite IDs - are maps not sufficient for your use-case?
Just tossing in my $.02 on this thread. I'd lean away from URI-based IDs to solve this - it feels like moving towards strings over data structures. Not saying that they don't have a place in general, but data structures feel better when possible (eg. structured editing), Regarding maps vs tuples, personally I lean towards tuples because they feel more datomic like, but perhaps it's just a preference on my end.
Maps seem to be sufficient :thumbsup:
I guess it's largely a matter of familiarity. {crux.db.id #crux/id {:twitter/id 1234}}
was a little surprising to me.
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