Fork me on GitHub
#xtdb
<
2020-10-23
>
Toyam Cox00:10:13

https://github.com/juxt/crux/discussions/1167 I think I should just write things both ways and see if there is a performance hit for using submit-tx to check for truthfullness

jarohen08:10:50

Hi - apologies, this one slipped through our net - will head over there now 🙂

julienvincent01:10:50

Another question:

{
  :query {
    :find [e]
    :where [[e :model 'user']
            (or (and [e :model-1 'user']
                     [e :model-2 'thing'])
                [e :model-3 'user'])]
  }
}
seems like a valid query to me - especially when comparing against https://github.com/juxt/crux/blob/master/crux-test/test/crux/query_test.clj#L578. The error I get is:
Or requires same logic variables: [[:and [[:triple {:e e, :a :model-1, :v 'user'}] [:triple {:e e, :a :model-2, :v 'thing'}]]] [:term [:triple {:e e, :a :model-3, :v 'user'}]]]
Not sure how to interpret that or what to change

Toyam Cox02:10:14

Why do you have 'user' all over the place?

julienvincent03:10:30

not a real query, just me copy pasting parts of a larger query to try reproduce the issue. The value can be anything with the same result

jarohen07:10:25

the single-quoting is likely what's causing the above error message, though - if you want to match against a string, you'll need to use double-quotes in Clojure, "user" etc. what's happening is that Clojure is interpreting these as symbols rather than strings, and so Crux treats them as logic variables

julienvincent09:10:21

Aha! that was it, thanks

🙏 3
Toyam Cox02:10:49

anyway, it seems to be that it doesn't like :model-3 not being used in the and for some reason

julienvincent03:10:57

Well, more the use of a eav tuple. the attribute could be anything with the same result it would seem

Toyam Cox06:10:52

Where can I learn about things like or and not-join?

jarohen08:10:29

This is an area where our documentation's currently lagging behind our implementation, I'm afraid - we're actively working on improving this at the moment 🙂 You've got the correct use of or and and in your example above, FWIW (with the change to double-quotes), and not works in a similar way. not-join additionally allows you to specify that only some of the variables should be unified between the wider query and the body of the join (a simple not tries to unify all the variables that they have in common) - there are a few examples of it here: https://github.com/juxt/crux/blob/master/crux-test/test/crux/query_test.clj#L621

Toyam Cox17:10:21

Give me a document to edit, I know I can change your site documentation via git. I'll be happy to document special abilities in transactions and queries, but don't want to clutter your documentation layout.

refset11:10:18

@U013YH4QPD0 hey sorry to keep you waiting on a response. In case you did still want to help out: If you want to edit our docs and preview the changes locally, you can now use this pre-built bundle https://github.com/crux-labs/crux-site-mock This is probably the adoc where you would want to elaborate on the Rules section https://github.com/juxt/crux/blob/master/docs/reference/modules/ROOT/pages/queries.adoc And here is a very recently opened issue which any such changes would help to solve https://github.com/juxt/crux/issues/1203 🙏

julienvincent18:10:43

Is there some alternative to the missing? expression in crux? Currently I am just setting the attribute to nil explicitly and querying for where it is (= ?e nil)

Toyam Cox19:10:52

I was told I could not-join

Toyam Cox19:10:15

If you know a key, you can match on nil for in a transaction

refset22:10:59

assuming you don't also need to handle explicitly stored nil values, you should be able to use this clause as an equivalent to missing?:

(not-join [eid]
          [eid :my-attr _])
For reference, this was discussed on a Zulip thread here: https://juxt-oss.zulipchat.com/#narrow/stream/194466-crux/topic/How.20to.20query.20for.20entities.20without.20a.20specific.20attribute.3F If you do need to also handle explicitly stored nil as well then you'll need an or, and may even be better served by a rule

julienvincent14:10:43

While this works, it seems to have a drastic effect on the performance of the query

julienvincent14:10:21

on a small data-set (100) this seems to have a 300ms impact. At least in my specific usage of it, which is part of some query generation.

refset14:10:40

I should have mentioned that we do have this semi-unofficial get-attr predicate which is near-enough the same as missing? but created purely to optimise retrieval of "leaf vars" ...so worth checking out if you're still looking at performance: https://github.com/juxt/crux/blob/33e1947f8d744e16c5cb13bddb580a5edbdd068d/crux-test/test/crux/query_test.clj#L1044