ok, well, I have a simple test case which shows that unionDefaultGraph certainly affects the result. I have opened
https://issues.apache.org/jira/browse/JENA-304 Simon From: Andy Seaborne <[email protected]> To: [email protected] Date: 08/24/2012 06:39 AM Subject: Re: mixing FROM and FROM NAMED with unionDefaultGraph=true On 24/08/12 11:25, Andy Seaborne wrote: > On 23/08/12 22:51, Simon Helsen wrote: >> Currently, TDB/ARQ does not do this, but only picks matches >> from graphUri1. Given that unionDefaultGraph=true should merge all named >> graphs into the default graph, this is surprising. To elaborate a bit, we >> found that the following query >> >> SELECT ?o >> FROM NAMED <graphUri2> >> WHERE { ?s <somePredicate> ?o } > > Bug. Or maybe not. The code specifically tests for the case of unionDefaultGraph and not specificed graphs on the dynamic datasets description. The code is in: com.hp.hpl.jena.sparql.coreDynamicDatasets It moved from TDB only a few days ago but no functionality changed. It is still the case that if you did specific the default graph at all, then that applies, regardless of union-setting. And of course the real (storage) default graph and the union graph both have URI names. Andy > If you specify the dataset description, you are giving a complete > description. There is an empty default graph in that description. > >> does pick results from graphUri2 (when run with unionDefaultGraph==true). >> Also, when we execute the following query: >> >> SELECT ?o >> FROM <graphUri1> >> FROM NAMED <graphUri2> >> WHERE { graph ?g { ?s <somePredicate> ?o } } >> >> then tdb seems to pick results from graphUri2 which is as expected. >> >> We were thinking that explicit FROM/FROM NAMED clauses simply ignores the >> unionDefaultGraph=true switch which could then explain the behavior of >> the >> first query above, but it doesn't explain the one of the second query. >> >> Feedback on this is welcome. >> >> thanks, >> >> Simon >> >
