Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix multiple optionals #248

Merged
merged 10 commits into from
Apr 27, 2023
Merged

Fix multiple optionals #248

merged 10 commits into from
Apr 27, 2023

Conversation

RickMoynihan
Copy link
Member

@RickMoynihan RickMoynihan commented Apr 14, 2023

TPX: matcha: fix multiple optionals

Issue: #21

In short: handling of optional clauses in matcha queries was returning incorrect results (depending on order). Root cause of that was the use of core.logic/conda where core.logic/conde should be used. But that change necessitates extra processing of the the raw core logic results (for both select and build macros).

Summary of changes

build

We infer which projected vars in the constructed map are optional. Knowing that, and having a solution we either set the (top level!) keys to the value from the solution (a set, if multiple values were returned by core.logic) or remove those keys.

We also rewrite the query by extracting the optionals and appending them at the end of a query.

While this should make no difference to core.logic it could make a difference in a SPARQL query, so one needs to be aware that those two are not the same.

select

  1. After conda -> conde change, we get different results.
  2. We want the results to as close to what a SPARQL query would return.

For example, a SPARQL query returns:

(def DB1 [(->Triple :john :status :online)
            (->Triple :john :prop1 "A")
            (->Triple :john :prop1 "B")
            (->Triple :john :prop2 :x)
            (->Triple :john :prop2 :y)])

(select [?o ?p ?x]
    [[?o :status ?status]
     (optional [[?o :prop1 ?p]])
     (optional [[?o :prop2 ?x]])]
    DB1)
 
;; result we expect, and what we would get in SPARQL: 
([:john "B" :y] [:john "B" :x] [:john "A" :y] [:john "A" :x])

;; result we get, after `conde` change, but without processing the solutions:
([:john "B" _0] [:john _0 _1] [:john "A" _0] [:john _0 :y] [:john _0 :x])

;; And if we remove the :prop1 relations from DB1, we should get:
([:john _1 :y] [:john _1 :x])

;; but without processing the solutions from `core.logic` we get:
([:john _0 _1] [:john _0 :y] [:john _0 :x])

The changes to select macro are cleaning up the unbound variables.

rosado added 2 commits April 3, 2023 11:18
Some `select` tests are broken due to changes in this commit.
src/grafter/matcha/alpha.clj Outdated Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
rosado and others added 2 commits April 21, 2023 14:24
Breaking change, `select` results should be more in line with SPARQL
query results.
src/grafter/matcha/alpha.clj Outdated Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
test/grafter/matcha/alpha_test.clj Show resolved Hide resolved
@rosado rosado marked this pull request as ready for review April 27, 2023 09:00
@RickMoynihan RickMoynihan merged commit 13e96ed into main Apr 27, 2023
@RickMoynihan
Copy link
Member Author

Thanks a million for this @rosado it's great work! 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants