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

Inefficient SPARQL generation #281

Open
luxbe opened this issue Nov 20, 2024 · 0 comments
Open

Inefficient SPARQL generation #281

luxbe opened this issue Nov 20, 2024 · 0 comments

Comments

@luxbe
Copy link
Contributor

luxbe commented Nov 20, 2024

When SOQL is translated into SPARQL, duplicate graph patterns can be generated:

SELECT p FROM Person p WHERE p.phone.number = :phoneNumber AND p.phone.brand = :brand
SELECT ?x WHERE {
    ?x a <http://krizik.felk.cvut.cz/ontologies/jopa/types#Person> .
    ?x <http://krizik.felk.cvut.cz/ontologies/jopa/attributes#hasPhone> ?phone .
    ?phone <http://krizik.felk.cvut.cz/ontologies/jopa/attributes#phoneNumber> ?phoneNumber .
    ?x <http://krizik.felk.cvut.cz/ontologies/jopa/attributes#hasPhone> ?phone .
    ?phone <http://krizik.felk.cvut.cz/ontologies/jopa/attributes#brand> ?brand .
}

When multiple nested attributes exits (e.g. p.phone.number and p.phone.brand), they both generate the same triple ?x <http://krizik.felk.cvut.cz/ontologies/jopa/attributes#hasPhone> ?phone .

While this should not have any performance impacts, because the SPARQL Parser should optimize the SPARQL query, it makes debugging the generated SPARQL harder and also leads to more traffic having to be send to the database.

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

No branches or pull requests

1 participant