Weird.

I ran this script with Fuseki v3.6.0 "--mem" and also "--memTDB" for steps up to and including 6.


https://gist.github.com/afs/cd6953b06985dde37a9581134ec13165

There something going on with TIM because I'm seeing empty graph5 with TIM but not with TDB.

I may have seen no results once and then I changed:

> 6. Check the contents of the store:
>
>      rsparql --service http://localhost:3030/ds/query "SELECT * WHERE
> {Graph ?G {?s ?p ?o}} ORDER BY ?G"

There are "" quotes around a "*" and it's a script. Could you try ''-quotes please?

I'll try step 7.

    Andy

On 05/03/18 23:56, Dave Reynolds wrote:
I've been trying to debug some weird behaviour in my test cases and think they are due to a bug in memory-backed fuseki stores.

However, the behaviour is so odd and hard to reproduce I'd like some confirmation that someone else sees the same effect before opening a JIRA.

# Steps to reproduce

[Sorry this is convoluted but all my attempts to simplify fail to show the suspected bug.]

1. Fresh download of fuseki 3.6.0.

2. Start an in memory server in one shell:

     fuseki-server --mem --update /ds

3. Create test data with two statements about one resource:

     echo 'prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#>
prefix eg:    <http://localhost/test/>
eg:r4 a eg:Resource; rdfs:label "r 4" .' > update.ttl

4. Use the graph REST API to put the data into a named graph:

     s-put http://localhost:3030/ds/data http://localhost/graph5 update.ttl

5. Run a sparql update which will delete the original statements from the graph and add some replacement statements to a new graph:

     rupdate --service=http://localhost:3030/ds/update '
    DELETE {GRAPH ?G {<http://localhost/test/r4> ?p ?o}} WHERE {GRAPH ?G {<http://localhost/test/r4> ?p ?o}};
     INSERT DATA { GRAPH <http://localhost/test/r4> {
        <http://localhost/test/r4> <http://www.w3.org/2000/01/rdf-schema#label> "r 4 modified" .         <http://localhost/test/r4> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://localhost/test/Resource> .
     } }'

6. Check the contents of the store:

    rsparql --service http://localhost:3030/ds/query "SELECT * WHERE {Graph ?G {?s ?p ?o}} ORDER BY ?G"

At this point the store *should* contain two statements in graph http://localhost/test/r4. With a TDB-backed fuseki that's what I see. With the memory backed fuseki I see an apparently empty store.

If other named graphs are populated with other unrelated data they will seem to have disappeared as well.

7. Now reinsert the original data, running step 4 again and check by running step 6 again. At this point both the "missing" statements from graph http://localhost/test/r4 reappear, as does the reinserted original statements in http://localhost/graph5.

# Simplifying the test case

So far ...

   - I've failed to reproduce this outside of fuseki.

  - I've failed to reproduce this without mixing graph operations and update operations.

  - If I reduce the inserted/updated data to a single statement instead of a pair of statements it passes.

   - If I try with at empty TDB store it passes.

   - I get the same behaviour from 3.4.0 as from 3.6.0.

Any of these failures may be user error on my part, it has been so hard turning an apparently non-deterministic error into something reproducible that I'm no longer sure of anything :(

Am I going mad or does anyone else see the same behaviour?

Dave



Reply via email to