Fork me on GitHub

How do you create a query which will return all the entity IDs that have :foo key but that don’t have the :bar key? Thanks


Hi again@U3SG7RX7A - this should do it:

{:find [?e]
 :where [[?e :crux.db/id _]
         [?e :foo _]
         (not [?e :bar _])]}


unfortunately query_test.clj is still the best source of guidance on all the query options and syntax:


Strictly speaking, this is probably not a Crux question, but ... when I execute my unit tests that use a standalone in-memory Crux node I get lots of log messages within the test output that clutter it up: Testing my-system.crux-test Feb 04, 2020 12:51:38 PM$eval1342$fn__1345 invoke WARNING: Using fsync on MemKv has no effect. Feb 04, 2020 12:51:38 PM$eval1342$fn__1345 invoke WARNING: Using fsync on MemKv has no effect. Can someone point me in the direction of information on how to redirect the logs to '/dev/null' or a file?


We have an open issue to clarify & clean up the MemKv warnings in particular: In general though, you can configure a logback.xml to suppress warnings (`level="ERROR"`). You need to add a logback-classic dependency to your project.clj / deps.edn and then create a logback.xml file. There are quite a few examples in the Crux repo which might help:;q=logback&amp;unscoped_q=logback


I'll check it out. Thanks!


Worked perfectly, once I put the logback.xml file in the test directory. I've never attempted to wrangle Java/Clojure logging before. I'll have to do some research to see if one can do this in "pure" Clojure, without the logback.xml file (timbre?).

🙂 4

Excellent, I'm glad it worked. Unfortunately that's the limit of my logging knowledge though!


If I understand :crux.tx/cas properly then something like the following: [:crux.tx/cas nil {:crux.db/id eid k-entity k-entity-type k-type-name valid-name}] will fail if the eid already exists within Crux. Does it make sense to ask if there's some kind of transaction that allows one to execute an arbitrary predicate and only continue if the predicate returns truthy? Perhaps something like: [:crux.tx/cas (my-fn-that-checks-for-crux-state eid) {:crux.db/id eid k-entity k-entity-type k-type-name valid-name}]


This topic overlaps with transaction functions, which has a whole issue thread covering a lot of detail... but the short story is that Crux relies on transaction operations executing consistently regardless of whether documents have been evicted or not. Any operation that peeks inside a given document will inevitably evaluate differently on a second run (e.g. by another node, or during re-index) if that document gets evicted in the meantime, and therefore nodes can easily arrive at inconsistent states. If you're careful and confident in how you combine these things then it can work, but for now we have hidden transaction functions behind a feature flag


Predicates get a specific mention too as a possible option in the design space:


Yes, at thorny issue indeed!