Would something like this work?

(def reservations-rules
  '[[(reservation-quantity ?p ?s ?rq)
     [?r :reservation/product ?p]
     [?r :reservation/storage ?s]
     [?r :reservation/quantity ?rq]]
    [(reservation-quantity ?p ?s ?rq)
     (not-join [?p]
               [?r :reservation/product ?p]
               [?r :reservation/storage ?s])
     [(ground 0) ?rq]]])

(defn find-quantities-for-product [product-eid]
  (d/q '[:find ?sid ?pid ?q
         :keys storage/id product/id quantity
         :in $ % [?p ...]
         :where
         [?sp :storage.product/product ?p]
         [?s :storage/products ?sp]
         [?s :storage/id ?sid]
         [?p :product/id ?pid]
         [?sp :storage.product/quantity ?sq]

         (reservation-quantity ?p ?s ?rq)

         [(- ?sq ?rq) ?q]]
       (d/db conn-mem2) reservations-rules product-eid))

Assuming I got your schema right and trusting a few tests, I think this should work. But I'd also consider splitting it up into multiple queries and move the logic from the query into the code.

nm, yes, those are the rules I would suggest too.

Sooner or later, all variables inside a not will need unification. If I understand the semantics correctly, then in this case, the difference between not and not-join is that when invoking the second version of the rule reservation-quantity , we don't want to (indeed cannot) unify ?r .

I think he still needs to unify on ?s

depends on his schema, but it looks like a reservation is found by matching a storage and a product

?s is unified before calling reservation-quantity

So either the first version of the rule succeeds, with a unified reservation, or the second rule succeeds, but (and this is why using or wouldn't work) both versions of the rule never succeed at the same time

Your observation on the schema is the assumption I made when testing this too. As an aside, if the product entities referenced the reservations directly, this query would have been a lot easier to write.

adding ?s to the not-join gives exactly what I need! for my understanding, is it possible to write this without rules? or is this “either or” behavior exclusive to rules? thank you very much @U024X3V2YN4 and @U09R86PA4! 🙏

You can use or+and. This is just sugar for rules

The xor behavior is from the two implementations having mutually exclusive matches

They have the same two clauses, but one not-join-s them the other doesn’t

yeah, just tried with or/and it gives the same result :thumbsup:

@U3L6TFEJF where did you need to add the ?s ? Inside not-join [?p ?s] ?

gotcha, I’ll commit the not-join pattern to my brain! one more question for my understanding: why doesn’t or-join work here? intuitively I’m asking for “this value or 0”, so it seems I’m not understanding what or-join means in Datomic fully :thinking_face:

@U024X3V2YN4 yep!

ahh: > With or clauses, you can express that one or more logic variables inside a query satisfy *at least one* of a set of predicates.

You are wondering why this doesn't work?

(or-join [rq]
         (and [?r :reservation/product ?p]
              [?r :reservation/storage ?s]
              [?r :reservation/quantity ?rq])
         [(ground 0) ?rq])

If a product has a reservation, it will return the quantity both with and without the reservation applied

yeah, I was thinking about or as “this or that, but not both”, but reading the docs it’s clear that it matches at least one

Exactly 😉

clarity achieved, cheers to you both! 🌸

For my own clarity: Why was adding ?s in the not-join needed?

for whatever reason, without ?s in the not-join products in storages with no reservation don’t get included in the result

Of course, that makes sense. Not having ?s in the vector means the unification of ?s to only those storages with reservations "escapes" the not-join .

always always always pass the db as the primary argument to a function that queries a database.

@U050ECB92 yessir, this is still very much at the sketching stage so I’m taking some liberties :thumbsup:

My tests would seem to indicate dispite the succesful schema txn, there is no fulltext index generated for entities with :patient/name

It seems that fulltext only applies to :db/valueType :db.type/string .

I hope others can come up with a better workaround, but if you want to keep the tuple model I can suggest something like this:

(def schema [{:db/ident :
              :db/valueType :db.type/long
              :db/cardinality :db.cardinality/one}
             {:db/ident :
              :db/valueType :db.type/keyword
              :db/cardinality :db.cardinality/one}
             {:db/ident :
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/fulltext true}
             {:db/ident :
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/fulltext true}
             {:db/ident :
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/fulltext true}
             {:db/ident :
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/fulltext true}
             {:db/ident :
              :db/valueType :db.type/instant
              :db/cardinality :db.cardinality/one}
             {:db/ident :
              :db/valueType :db.type/instant
              :db/cardinality :db.cardinality/one}
             {:db/ident       :patient/name
              :db/valueType   :db.type/tuple
              :db/cardinality :db.cardinality/one
              :db/fulltext    true
              :db/tupleAttrs  [:
                               :
                               :
                               :
                               :
                               :
                               :
                               :

Then you can run queries like this:

[:find ?long
      :where
      [(fulltext $ : "s1") [[?e ?val]]]
      [?e :patient/name ?pn]
      [(untuple ?pn) [?long]]]