Fork me on GitHub

Hey all, happy Friday ๐Ÿ™‚ We're looking to migrate Crux over to Maven Central shortly - we've got a couple of non-Clojure modules coming soon, and would generally like to make Crux more accessible/appealing to folks outside of the Clojure community too. We've mirrored our Clojars dependencies onto Central, and have re-released 1.17.1 (currently as 1.17.1-rc1) so that users can migrate without having to upgrade Crux. Would appreciate it if anyone who has a moment can update their Crux coordinates and let me know if anything breaks! ๐Ÿ™ * GroupId is now pro.juxt.crux * We've dropped the YYMM date prefix and -alpha/`-beta` suffixes, the latter mostly so that we can do proper pre-releases rather than having suddenly reached a particular milestone of stability (although don't let me stop you cracking out the champagne should you wish ๐Ÿพ) tl;dr juxt/crux-core "21.06-1.17.1-beta" => pro.juxt.crux/crux-core "1.17.1-rc1" Thanks, and have a good weekend ๐Ÿ™‚

๐Ÿ‘ 20
๐Ÿพ 2

Are you using the same namespaces? That might cause problems for people if they accidentally get both versions on the classpath.


(as can happen if you, for example, bring in a library which builds atop crux)


Hey @U09LZR36F ๐Ÿ‘‹ For our mirrored dependencies, no - they've been run via mranderson; for Crux, yes, on the assumption that having multiple dependencies on Crux within one application is sufficiently uncommon, and that people who do are already aware of it. Obviously keen to hear of any cases where this may cause issues ๐Ÿ™‚


When using maven, this can happen accidentally unfortunately.


It's usually a very frustrating few days of pain trying to get to the bottom of something then realising you have both juxt/crux-core and pro.juxt.crux/crux-core on the classpath.

dominicm15:06:41 maven has relocation to support this, which is currently WIP on Clojars.


Thanks for the relocation pointer - will include this when we next deploy to Clojars in anticipation of that feature becoming available ๐Ÿ™


Indeed - have had a few of those days myself...


Often (IME, at least) they're with libraries much deeper in the dependency tree, referred to by multiple other libraries (the dependency diamond). Our assumption is that Crux is rarely (if ever?) a transitive dependency - rather, a direct dependency of the final end-user application - as I say, though, keen to hear of examples to the contrary ๐Ÿ™‚


I suspect the answer is no, but does crux support references to other documents in the same way as datomic?


Not in exactly the same way, since there's no upfront schema and it uses explicit IDs, but it certainly does allow you to traverse the graph - thanks to duck-typing of triple clause reference lookups purely at query time / "schema on read"


hmm, but what constitutes a โ€œpointerโ€ from one document to another?

Jacob O'Bryant17:06:03

anything basically. I usually use UUIDs or maps. e.g. if you have two docs in the db like this:

{:crux.db/id #uuid "abc..."
 :foo/bar #uuid "123"}
{:crux.db/id #uuid "123..."
 :msg/text "hello"}
Then you could do a query like this:
:where '[[doc-a :foo/bar doc-b]
         [doc-b :msg/text text]]
When the query runs, crux will bind doc-b to #uuid "abc...", and then it'll see if there are any documents with :crux.db/id set to #uuid "abc...".* But no need to define up front that the value of :foo/bar is a pointer--when you run a query like the one above, Crux will decide at runtime that it should be treated as a pointer. (*technically the query engine might not do it in that order, but wrt this discussion it doesn't make a difference)

๐Ÿ‘ 9
Jacob O'Bryant17:06:23

same thing goes for pull and crux.api/entity -- if you put something where a document ID is supposed to go, Crux will happily treat it as a document ID


@U7YNGKDHA thatโ€™s very flexible and convenient, many thanks for the explanation!

โž• 9
๐Ÿ‘Œ 3

so that a graph is formed