On 05/04/13 15:23, David Jordan wrote:
I plan to review the Jena source code this weekend to understand what
needs to be done to support an alternative storage implementation. I
had heard on this group a while ago that there was some planned
effort to simplify the storage interface to make this easier. Has
that been done yet? Briefly perusing the code last night, it seemed
like the graph package is where I should focus my attention. I’d
appreciate any other pointers to relevant code that would need to be
examined to support an alternative implementation. We are probably
going to look for more of an in-memory implementation that would be
backed up by a storage facility that is not relational, so I am
thinking the manner in which TDB operates may be a better fit than
SDB. Any helpful suggestions are greatly appreciated.
Look at TDB as an example for integration (although it does integrate
more just basic features) (... which is a non relational engine with
heavy in-memory, same process caching ...)
Single graph:
Implementation can extend GraphBase.
For SPARQL, that will work on it's own - going deep to improve
efficiency, depending on the features of the storage implementation
0/ Check the examples in SVN in
https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src-examples/arq/examples/
S1/ Implement DatasetGraph for the storage
S2/ Implement at least OpExecutor.execute(OpBGP opBGP, QueryIterator input.
S3/ Glue together by registering a query engine.
See "MyQueryEngine" example
then implement additional features in OpExecutor as matter to you.
Andy
