Andy, Thanks for the prompt reply. This is definitely new with 2.3.1 as my updates have been working fine and only broke with the upgrade to 2.3.1.
I tried it with the latest 2.4.0 SNAPSHOT (apache-jena-fuseki-2.4.0-20151210.110356-4.tar.gz) and it's still not working correctly. I'm using TDB and for my update examples the testGraph was empty. However, I initially encountered it on a non-empty graph so I'm fairly confident in saying it fails on both empty and non-empty graphs. Also, I repeated the example inserts using different subjects with the latest snapshot and it fails on both the first insert (i.e. empty graph) and on subsequent inserts (i.e. non-empty graph). Also, I'm running fuseki in a docker container but can't image that would make any difference. Let me know if I can provide you more information. Howard On Thu, Dec 17, 2015 at 2:15 PM Andy Seaborne <[email protected]> wrote: > Hi there, > > yes both triples should be in the testGraph. > > This looks like JENA-1092 [*], for the change Jena 3.0.0, Jena 3.0.1 > which is now fixed. It would be helpful if you could try out a > development build [+] > > The accurate rewrite is: > > INSERT { > GRAPH testGraph: { > entryNS:c02db2e0-a4e3-11e5-8b21-63a5a521ceff a common:SomeClass ; > common:hasCreateTime ?now . > } > } > WHERE { > GRAPH testGraph: { > BIND(now() as ?now) > } > } > > i.e. GRAPH in both parts. > > > It would help me for another matter I am investigating to know > > What storage are you using? > Is there any data in testGraph: ? > > At 2.12.1, there was a chnage to make it exactly like the rewrite above. > In TDB, however all graphs "exist" so this (currently) messes up > consistency of update (but not query - reason currently unclear). If > what you observe is 2.3.0/2.3.1 chage this is not the issue as that part > has not changed. > > Andy > > [*] https://issues.apache.org/jira/browse/JENA-1092 > [+] > > https://repository.apache.org/content/repositories/snapshots/org/apache/jena/apache-jena-fuseki/2.4.0-SNAPSHOT/ > > build 12 (Thu Dec 17 10:24:10 UTC 2015 or later). > > > > On 17/12/15 19:45, Howard Burrows wrote: > > I'm experiencing what appears to be a bug using "WITH <graph> > INSERT/WHERE" > > in the latest Fuseki release (2.3.1). If I attempt to insert a triple > with > > a predicate of 'rdf:type' (or 'a') it gets inserted into the default > graph; > > other triples get correctly inserted into the specified graph. The > > following is an example insert that will demonstrate the problem. After > > the insert the triple with the rdf:type predicate will be in the default > > graph and the triple with the common:hasCreateTime triple will be in the > > testGraph. I expect both triples to be in the "testGraph" graph > > > > PREFIX common: <http://www.example.com/common> > > PREFIX entryNS: <http://www.example.com/entries> > > PREFIX testGraph: <http://www.example.com/testGraph> > > > > WITH testGraph: > > INSERT { > > entryNS:c02db2e0-a4e3-11e5-8b21-63a5a521ceff a common:SomeClass ; > > common:hasCreateTime ?now . > > } > > WHERE { > > BIND(now() as ?now) > > } > > > > If, however, I don't use WITH and specify the graph inside the INSERT > > clause using GRAPH <graph> {} it works as expected. For example: > > > > PREFIX common: <http://www.example.com/common> > > PREFIX entryNS: <http://www.example.com/entries> > > PREFIX testGraph: <http://www.example.com/graph> > > > > INSERT { > > GRAPH testGraph: { > > entryNS:c02db2e0-a4e3-11e5-8b21-63a5a521ceff a common:SomeClass ; > > common:hasCreateTime ?now . > > } > > } > > WHERE { > > BIND(now() as ?now) > > } > > > > Am I not understanding the semantics of how WITH <graph> works.... or is > > this a problem with the latest release. This was not the case with 2.3.0 > > > > Thanks, > > > > Howard Burrows > > > >
