HI Minto The problem ist that the current implementation of TdbStorageProvider is imple ignoring the default-graph argument. So that's what should be fixed.
Cheers, Reto On Mon, Jul 15, 2013 at 10:49 AM, Minto van der Sluis <[email protected]> wrote: > Hi, > > Currently I already use an empty default graph. I don't remember who but > someone told me to do so when I started to use Clerezza. The following > is a snippet of my code: > > ... > MGraph graph = new SimpleMGraph(); > > try { > return clerezzaManager.executeSparqlQuery( query, graph, true ); > } catch( ParseException e ) { > throw new RuntimeException( e ); > } > ... > > The empty default graph is not used by me. I just want to run the query. > > Regards, > > Minto > > > > Op 14-7-2013 19:48, Andy Seaborne schreef: >> (sorry - I'm bandwidth reduced ATM - connected by phone) >> >> Putting in an empty default graph would be better. A dataset always >> has a default graph which is why the code assumes it's not null. >> >> If the DatasetImpl.setDefaultModel is fixed, are there any other >> barriers? >> >> While null isn't a good idea, the code can be made more robust. But >> by probability there will be other code that does not check for null >> as it shouldn't be. >> >> One fix is to have setDefaultModel add an empty (immutable) model. >> >> The bit I don't quite understand here is that things only get >> converted to quads for TDB and the default graph is fixed so I don't >> see the connection with setDefaultModel. >> >> You can have concurrent queries - Fuseki does all the time. Either >> the right MRSW lock or transactions will work. (Fuseki uses >> transactions always - for in-memory it creates an associated >> transactional control object). >> >> Andy >> >> On 14/07/13 18:12, Reto Bachmann-Gmür wrote: >>> Hi Minto >>> >>> I'm sorry for having introduced this problem. I just noticed that >>> BaseTdbTcProvider completely ignored the specified default graph. Not >>> sure what I thought exacly setting it to null. I guess it was the >>> incomplete ste of setting it to the actually wanted default graph. >>> >>> The problem is that by the jena design we would need to prevent >>> concurrent queries with different default graphs. So I think it might >>> be better to add a FROM-clause to the query if the query doesn't >>> already has one. This would require again some parsing. The preparser >>> seems to be the place to do this. WDYT, can we do a solution that >>> actually provided support for the specified default graph or should we >>> first just provide a release that ignores it without NPE? >>> >>> >>> Cheers, >>> Reto >>> >>> On Sun, Jul 14, 2013 at 11:58 AM, Minto van der Sluis <[email protected]> >>> wrote: >>>> Hi Reto, >>>> >>>> If I am correct the NPE I discovered will always happens for fastlaned >>>> queries on Jena TDB based TcProviders due to the following line present >>>> in BaseTdbTcProvider.java: >>>> >>>> getDataset().setDefaultModel(null); >>>> >>>> The NPE can be clearly seen in DatasetImpl if model is null: >>>> >>>> @Override >>>> public void setDefaultModel(Model model) >>>> { >>>> // Assumes single writer. >>>> removeFromCache(dsg.getDefaultGraph()) ; >>>> addToCache(model) ; >>>> dsg.setDefaultGraph(model.getGraph()) ; >>>> } >>>> >>>> Did you have anything special in mind when you added the null model? >>>> >>>> Regards, >>>> >>>> Minto >>>> >>>> Op 12-7-2013 23:50, Reto Bachmann-Gmür schreef: >>>>> Thanks Minto. I would rather not withdraw the release candidate but >>>>> have a new release very soon (max a couple of weeks). >>>>> >>>>> Reto >>>>> >>>>> On Fri, Jul 12, 2013 at 10:48 PM, Minto van der Sluis >>>>> <[email protected]> wrote: >>>>>> Fixed this with commit r1502677 (CLEREZZA-802) >>>>>> >>>>>> Please have a close look. Might need to be part of the pending >>>>>> release >>>>>> as well. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Minto >>>>>> >>>>>> Op 12-7-2013 18:14, Minto van der Sluis schreef: >>>>>>> This time I end up with an NPE, see stack below. >>>>>>> >>>>>>> My changes resulted in the following >>>>>>> >>>>>>> public Object executeSparqlQuery(String query, TripleCollection >>>>>>> defaultGraph, boolean forceFastlane) throws ParseException { >>>>>>> TcProvider singleTargetTcProvider = null; >>>>>>> if (forceFastlane) { >>>>>>> singleTargetTcProvider = getSingleTargetTcProvider(); >>>>>>> } else { >>>>>>> final UriRef defaultGraphName = new >>>>>>> UriRef("urn:x-temp:/kjsfadfhfasdffds"); >>>>>>> SparqlPreParser sparqlPreParser = new >>>>>>> SparqlPreParser(this); >>>>>>> final Set<UriRef> referencedGraphs = >>>>>>> sparqlPreParser.getReferredGraphs(query, defaultGraphName); >>>>>>> if ((referencedGraphs != null) && >>>>>>> (!referencedGraphs.contains(defaultGraphName))) { >>>>>>> singleTargetTcProvider = >>>>>>> getSingleTargetTcProvider(referencedGraphs); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> if ((singleTargetTcProvider != null) && >>>>>>> (singleTargetTcProvider >>>>>>> instanceof QueryableTcProvider)) { >>>>>>> return >>>>>>> ((QueryableTcProvider)singleTargetTcProvider).executeSparqlQuery(query, >>>>>>> >>>>>>> null); >>>>>>> } >>>>>>> final QueryEngine queryEngine = this.queryEngine; >>>>>>> if (queryEngine != null) { >>>>>>> return queryEngine.execute(this, defaultGraph, query); >>>>>>> } else { >>>>>>> throw new NoQueryEngineException(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> private TcProvider getSingleTargetTcProvider() { >>>>>>> return providerList.first(); >>>>>>> } >>>>>>> >>>>>>> I guess the following like in >>>>>>> BaseTdbTcProvider.executeSparqlQuery() is >>>>>>> the culprit: >>>>>>> >>>>>>> getDataset().setDefaultModel(null); >>>>>>> >>>>>>> Stacktrace: >>>>>>> >>>>>>> java.lang.NullPointerException >>>>>>> at >>>>>>> com.hp.hpl.jena.sparql.core.DatasetImpl.addToCache(DatasetImpl.java:259) >>>>>>> >>>>>>> at >>>>>>> com.hp.hpl.jena.sparql.core.DatasetImpl.setDefaultModel(DatasetImpl.java:214) >>>>>>> >>>>>>> at >>>>>>> org.apache.clerezza.rdf.jena.tdb.storage.BaseTdbTcProvider.executeSparqlQuery(BaseTdbTcProvider.java:39) >>>>>>> >>>>>>> at >>>>>>> org.apache.clerezza.rdf.jena.tdb.storage.ScalableSingleTdbDatasetTcProvider.executeSparqlQuery(ScalableSingleTdbDatasetTcProvider.java:81) >>>>>>> >>>>>>> at >>>>>>> org.apache.clerezza.rdf.core.access.TcManager.executeSparqlQuery(TcManager.java:310) >>>>>>> >>>>>>> at >>>>>>> org.apache.clerezza.rdf.core.access.TcManager.executeSparqlQuery(TcManager.java:282) >>>>>>> >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>> Method)[:1.7.0_17] >>>>>>> at >>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17] >>>>>>> >>>>>>> at >>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17] >>>>>>> >>>>>>> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17] >>>>>>> at >>>>>>> org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)[12:org.apache.aries.proxy.impl:1.0.0] >>>>>>> >>>>>>> at >>>>>>> org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)[12:org.apache.aries.proxy.impl:1.0.0] >>>>>>> >>>>>>> at >>>>>>> org.apache.clerezza.rdf.core.access.$TcManager10360330.executeSparqlQuery(Unknown >>>>>>> >>>>>>> Source)[181:org.apache.clerezza.rdf.core:0.13.0.SNAPSHOT] >>>>>>> at >>>>>>> nl.overheid.stelsel.digimelding.astore.storage.clerezza.ClerezzaStorageProvider.query(ClerezzaStorageProvider.java:250)[209:astore-storage-clerezza:0.7.0.SNAPSHOT] >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> ir. ing. Minto van der Sluis >>>>>> Software innovator / renovator >>>>>> Xup BV >>>>>> >>>>>> Mobiel: +31 (0) 626 014541 >>>>>> >>>>> >>>> >>>> >>>> -- >>>> ir. ing. Minto van der Sluis >>>> Software innovator / renovator >>>> Xup BV >>>> >>>> Mobiel: +31 (0) 626 014541 >>>> >> >> >> > > > -- > ir. ing. Minto van der Sluis > Software innovator / renovator > Xup BV > > Mobiel: +31 (0) 626 014541 >
