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

INSERT USING appears not to respect graph restriction #655

Closed
vtermanis opened this issue Oct 20, 2023 · 3 comments
Closed

INSERT USING appears not to respect graph restriction #655

vtermanis opened this issue Oct 20, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@vtermanis
Copy link
Contributor

vtermanis commented Oct 20, 2023

Describe the bug
With data in multiple graphs, when performing a INSERT .. USING (NAMED) .. WHERE query, the WHERE clause still appears to be scoped to all graphs, not just the ones specified in the USING clause(s).

To Reproduce
Steps to reproduce the behaviour:

  1. Which version of Oxigraph are you using? On which platform?
    Official docker image oxigraph/oxigraph:v0.3.19

  2. A command line or a code snippet that triggers the bug.

    PREFIX ex: <http://example.org/ns#>
    
    CLEAR ALL;
    
    INSERT DATA {
        GRAPH ex:graph1 { ex:sub1 a ex:Thing . }
        # Having the same triple present in more than one graph ..
        GRAPH ex:graph2 { ex:sub1 a ex:Thing . }
    };
    
    INSERT {
        # .. and inserting a bnode-referenced triple against it ..
        GRAPH ex:public { ?s ex:prop1 [ ex:fromGraph ?g ] . }
    }
    # .. despite the single graph restriction
    USING NAMED ex:graph1
    WHERE {
        VALUES ?s { ex:sub1 } .
        # this appears to match both graphs
        GRAPH ?g { ?s a ex:Thing . }
    }
    • Expected: A single <bnode> ex:fromGraph ex:graph1 triple is added by the 2nd update query.
    • Actual: Two of these triples are added with objects ex:graph1 & ex:graph2
    • This happens with both USING and USING NAMED
@vtermanis vtermanis added the bug Something isn't working label Oct 20, 2023
@Tpt
Copy link
Collaborator

Tpt commented Oct 21, 2023

Thank you for this other great bug report!

I have started investigate it, my finding is that it is related to facebook/rocksdb#2343 (iteration inside of transaction does not enforces the given key prefix and, so, might iterate on the full index, causing unexpected reads). This RocksDB fix seems to fix the bug. I upgrade RocksDB in #656

Tpt added a commit that referenced this issue Oct 21, 2023
Fixes issue #655
@Tpt Tpt mentioned this issue Oct 21, 2023
github-merge-queue bot pushed a commit that referenced this issue Oct 21, 2023
Fixes issue #655
@vtermanis
Copy link
Contributor Author

I can confirm that the latest ghcr.io/oxigraph/oxigraph:main Docker image fixes this. Thank you!

@Tpt
Copy link
Collaborator

Tpt commented Oct 23, 2023

Released in 0.3.20. Thank you again!

@Tpt Tpt closed this as completed Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants