Fork me on GitHub
R.A. Porter01:01:12

I want to put up a PR to fix an issue with the crux-build module but I’d like to test my changes first. When I try to run directly, it errors out and I get tar file with issues. When I try to run lein build from the root of the repository, it fails because of mismatched Jetty versions. It’s a really small fix and I’d really like to contribute it but I’m never comfortable putting up a change if I can’t build and test it. Is there some configuration setup method missing from the README for building the app? Or is master just broken currently?

R.A. Porter01:01:34

My tired brain recalls there are differences between the BSD- and Linux-based versions of sed so I suspect the problem building just in that module regards that. I can probably fudge around that.

R.A. Porter02:01:48

Yep. Installing gnu-sed did it.


aha, thanks for flagging this up - yep, good shout to include this in a note in the README. I don't know enough about the differences between them to know whether we can make a small change to make it portable, or maybe whether we should consider another solution outside of sed (I daresay Windows will have similar issues)


If you Google you'll find shell solutions for this. I ran into similar issues with macos date vs. gnu date. Tldr; detect the correct binary and use a shell var to configure which to use.

R.A. Porter11:01:28

Well beyond the scope of my little change, but I wonder if swapping out the shell scripts for babashka might be the way to go.


we do like babashka 🙂 but unfortunately there're people using crux-build without a Clojure setup


ah, although maybe not that script, that might just be in our build pipeline in order to build the crux-builder artifact


Afternoon all - we've released a snapshot version of Crux to Clojars with a few bugfixes - set your Crux versions to dev-SNAPSHOT to pull it down. The next release will contain an optional index version bump to fix an eviction regression, introduced with the index performance improvements in 1.13.0. Some data remained in Crux after an eviction in certain cases - all personally identifiable information continued to be removed correctly, but some metadata remained in the bitemporal query indices. - If you're upgrading from <1.13.0 directly to this snapshot, or what will become 1.14.0, you'll need to re-index anyway because of the improvements in 1.13.0 - if you haven't yet upgraded to 1.13.0, it'd be worth considering holding off and upgrading directly to the next release. - If you've already upgraded to 1.13.0, and you know that you put, evict, and re-put the same entity, you'll need to re-index to fix this issue. - Otherwise, you can specify {:crux/index-store {:kv-store {:skip-index-version-bump [16 17]}}} in your config to opt out of this one. We also located an issue with eventually consistent doc stores where certain operations caused an unresponsive query, for which a fix is included in this snapshot. As always, thanks all for raising these issues, and please do continue letting us know if you find any others 🙂 @sagarvrajalal @kevin842 @levitanong

🎉 18
Jacob O'Bryant23:01:52

Hey, I'm upgrading from 20.09-1.12.1 to 20.12-1.13.0 and I'm getting java.lang.NoSuchFieldException: cooling-factor when I try to run a query (see the attached stack trace, and Any idea what might be causing that? I deleted the crux indexes before starting up the jvm by the way, and I also tried dev-SNAPSHOT.


Hey 🙂 thanks for the stack trace. It's not a problem I've seen before. Can you share (or describe) the query and any args being passed in to q? I might be reading it wrong, but it looks an issue during query compilation

Jacob O'Bryant23:01:31

sure--actually now that you mention that, I notice I am doing something a bit unusual in the query. I'm passing in the db as an argument:

(crux/q db
  {:find '[user]
   :full-results? true
   :args [{'now now
           'db db}]
   :where '[[user :user/id]
            (not [user :unsubscribed true])
            [(findka.essays.algo/should-send db user now)]]})
I'll try refactoring that

Jacob O'Bryant23:01:06

(though not sure if that would have anything to do with query compilation, since db is passed in at runtime?)

Jacob O'Bryant00:01:38

yep, refactoring that into a saner query fixed it


Ah, I only just saw the responses here. Thanks for sharing the query. Passing the db like this did use to work, but I think it's not really a good idea. The db is implicitly available as $ though, and if you want to do something even slicker then you can register a new query predicate, with access to the db ctx, like so:

Jacob O'Bryant13:01:07

No worries; the new refactored query is cleaner anyway.