It does, as of the recent 1.18.0 release: https://opencrux.com/reference/lucene.html#_checkpointing_lucene

that's great!

running crux nodes in ECS, so that's good to know

Hi @U052A8RUT your (edit) solution looks sensible enough to me, so if it works okay then you can probably move on already. However, we have a fairly similar looking solution for a similar sounding problem that might inspire a slightly simpler approach: https://github.com/juxt/crux/blob/64e6f1f15ef2e389c42b8f17533c000bed9d33d7/crux-test/test/crux/query_test.clj#L1776-L1779

in your solution where you have (not-join [e ?user-id] [e :list/user]) - without knowing how else ?user-id is used/bound, I'm not certain it will return what you want. Are you getting nil out of it? (Is it in the :find?)

i'm not sure i'm following entirely. To clarify: I want to retrieve docs where this attribute doesn't exist, as well as the docs where it does exist AND is equal to a param value.

Ha, no it is not in the :find

The entire query is:

{:find '[e], 
 :where '[[e :list/id ?id] 
          (or-join [e ?user-id] 
                   [e :list/user ?user-id] 
                   (not-join [e ?user-id] 
                             [e :list/user]))
          [e :list/scope ?scope-id]], 
 :args [{?user-id 1, 
         ?scope-id "case-1"}]}

This should work for you, I think:

(crux.api/q
{:find '[e],
 :in '[?user-id ?scope-id] 
 :where '[[e :list/id] ;; no need to capture ?id in the triple clause if you're not using it
          (or-join [e ?user-id]
                   [e :list/user ?user-id] 
                   (and (not [e :list/user])
                        [(any? ?userid)]) ;; this is a noop predicate to keep the variables in the or-join legs balanced
          [e :list/scope ?scope-id]]}
1
"case-1")

Thanks, I'll check it out soon

short answer: no 🙂 I get a distinct feeling I'm about to learn something about the innards of Clojure, though :thinking_face:

can repro locally, fwiw

should I post an issue?

sure, although I'm happy to take a quick look, see if anything stands out

ok, I'll hold and see what comes out. Thanks for looking into it 🙂

alright - in that time crux/submit-tx has gone from being implemented via extend-protocol to being implemented directly on a defrecord - I wonder if there's anything about defrecord s that mean their implementations bypass with-redefs in any way (some form of inlining, maybe?)

looks that way:

(defprotocol P
  (foo [_ a]))

(defrecord R []
  P
  (foo [_ a]
    a))

(with-redefs [foo (constantly 10)]
  (foo (->R) 42))

;; => 42

whereas:

(defprotocol P
  (foo [_ a]))

(defrecord R [])

(extend-protocol P
  R
  (foo [_ a]
    a))

(with-redefs [foo (constantly 10)]
  (foo (->R) 42))

;; => 10

to workaround, if you're looking to simulate crux/submit-tx throwing an error, you could try redef'ing one of the callees of that function instead - crux.api/conform-tx-ops might be a good shout

ok, thanks for the info and the workaround. Any chance the Crux implementation will change or will this be a trade-off of the internal implementation you have chosen?

it's unlikely to change, but obviously can't guarantee it - the fact that submit-tx calls conform-tx-ops isn't part of the public API 🙂

oh, I mean the change of going from extend-protocol to defrecord. That might have given you benefits that you do not want to revert for the sake of supporting with-redefs

oh, I see. yes, that one's similarly unlikely to be reverted - previously we were attaching the functionality to a Java class, whereas now we're using a Clojure record

you could also consider supplying your own implementation of PCruxNode to that function, with reify, say?

right. Now that I know it is not a bug and will stay, I'll take a look at my workaround options. Maybe it could be worth documenting in some test related part, the current behaviour was a bit surprising 🙂 Thanks for your support and looking into it, I also learned something about the Clojure internals 🙂

it's definitely fair to say that we've all learned a thing or two ☺️

if the protocol has extend via metadata set, then you could just change submit-tx to throw using with-meta

I don't think that'll help on this occasion I'm afraid - looks like Clojure takes behaviours defined on a defrecord in preference to both

callers of protocol functions have bytecode to check whether the receiver implements the protocol interface first, calling the method directly if it does, and only falling back to the other protocol resolution logic if it doesn't