On Thu, Mar 17, 2011 at 5:18 PM, Olivier Grisel <[email protected]> wrote:
> On 17 March 2011 16:37, Hasan Hasan <[email protected]> wrote: > > Hi Olivier > > > > Indeed, this "fastlane" support in executing sparql queries, where the > > underlying triple store is jena, is something that still on our to do > list. > > However, if you would like to contribute and provide a patch, that would > be > > really appreciated. > > Not sure about the effort needed to get the native TDB Dataset > encapsulated > > in the TripleCollection though. There may be some other wrappers > in-between > > which are inserted to provide security and locking mechanisms > > Ok thanks for your reply. Security and locking checks apart, making > the jena sparql engine able to fetch a TdbDataset instead of the > generic TcDataset wrapper would require to introduce a new dependency > between rdf.jena.tdb.storage and rdf.jena.sparql one way or another, > maybe moving the TcDataset class as an interface in the > rdf.jena.commons instead to avoid cyclic or unwanted dependencies. > No there must not be such a dependency. The solution I think should rougly look like this: TcProvider can Implement an additional Subinterface (say SparqlTcProvider) allowing to pass Sparql-queries to them. If a sparql query affects only graphs provided by the same SparqTcProvider the the query is forwarded to that provider, otherwise the current process aplies. > > Also it would be great to have support for fined grained support for > default and named graph in SPARQL queries with named graph mapped to > the Clerezza graph ids used by the TcProvider. In jena this seem to be > provided by: > > http://www.openjena.org/wiki/TDB/DynamicDatasets > > I wonder if this compatible with the current directory structure > implied by the TdbTcProvider#getMGraph implementation. > I agree. Possibly changes in tdb.storage are needed. Cheers, Reto
