Sorry, ignore what I said (stupid me!). Now I got what you said earlier about
DatasetGraph.add and .delete
The code I took over didn't implements DatasetGraph for our custom graph store,
which was why I got confused.
Now I have to rewrite our existing graph store code to implements DatasetGraph
interface.
With this, then I can simply pass it to the UpdateEngineMain constructor, which
then it will call my add/delete logic.
Sorry for my ignorance :-(
Thanks,
Z
________________________________________
From: Zen 98052 <z98...@outlook.com>
Sent: Thursday, September 17, 2015 3:00 PM
To: users@jena.apache.org
Subject: Re: jena technical doc
I looked at Jena code more thorough, and I think I found what I am looking for,
let me know if this is not the right way.
First, I create my own update engine worker (i.e. implements UpdateVisitor
interface), this is where I put all my logic to deal with update operations
against our back-end data store (I can look at the code in Jena's
UpdateEngineWorker.java)
Next is to create the main update engine, which will reference the update
engine worker above. The code is similar to Jena's UpdateEngineMain class
(especially the one in getUpdateSink method)
The code in this file will also create the UpdateEngineFactory instance,
basically same as the code in UpdateEngineMain.java
Finally, I just need to pass my instance of the UpdateEngineFactory to
UpdateEngineRegistry.addFactory method.
Let me know if I missed something.
Thanks,
Z
________________________________________
From: Zen 98052 <z98...@outlook.com>
Sent: Thursday, September 17, 2015 11:32 AM
To: users@jena.apache.org
Subject: Re: jena technical doc
Hi Andy,
I have follow up question for #2 after looking at DatasetGraph class, and
Jena's code sample for the update operation.
Which interface I can implement, so that I can do something like below:
* if the statement in SPARQL query is INSERT, then convert it to specific
custom logic (i.e. add new row to our custom data storage)
* if the statement in SPARQL query is DELETE, then convert it to specific
custom logic (i.e. remove the row from our custom data storage)
I see there is a UpdateExecutionFactory class, and not sure where to put my own
implementation.
Thanks,
Z
________________________________________
From: Andy Seaborne <a...@apache.org>
Sent: Thursday, September 10, 2015 10:39 AM
To: users@jena.apache.org
Subject: Re: jena technical doc
1. SPARQL Query and SPARQL Update are different languages (in the spec)
and have different APIs in Jena.
You can't (by design in the spec) pass a update where a query is
expected. It is always a parse error.
2. DatasetGraph.add(Quad) and .delete(Quad)
Andy
On 10/09/15 13:52, Zen 98052 wrote:
> Thanks Andy. Let me look at the code and some examples pointed by you.
> In the meantime, I have another question.
>
> I have following code where I validate if the SPARQL query string is SELECT
> statement or not.
>
> Query q = QueryFactory.create(queryString);
> QueryExecution qe = null;
> try {
> qe = QueryExecutionFactory.create(q, graphModel);
> } catch (QueryParseException e) {
> throw new RuntimeException(e);
> }
>
> if (q.getQueryType() != Query.QueryTypeSelect) {
> throw new UnsupportedOperationException("Only SELECT
> query is supported.");
> }
>
> This code works fine, but I want to support INSERT and DELETE operations too.
> If queryString is INSERT/DELETE, then this code
> QueryFactory.create(queryString); will throw exception.
> 1. Does Jena have a way for me to check the operation, and handle it
> accordingly?
>
> 2. Also, where is the integration point where I can convert SPARQL's
> INSERT/DELETE statement into my own implementation?
>
>
> Thanks,
> Z
>
> ________________________________________
> From: Andy Seaborne <a...@apache.org>
> Sent: Thursday, September 10, 2015 1:44 AM
> To: users@jena.apache.org
> Subject: Re: jena technical doc
>
> On 10/09/15 00:20, Zen 98052 wrote:
>> Hi,
>>
>> I am new to Jena programming.
>>
>> I am using Jena's SPARQL API to process the query and translate the
>> query into accessing our custom back-end storage. I am now familiar
>> with basic code like subclassing the GraphBase and QueryIter with my
>> own implementation. But I need to learn more on extending the query
>> optimization.
>>
>>
>> I found this doc
>> (http://jena.apache.org/documentation/query/arq-query-eval.html) is a
>> good start, but it's not comprehensive enough for beginner like me.
>> Even the Java API doc also doesn't have much info, for example I was
>> looking at OpExecutorFactory class at
>> https://jena.apache.org/documentation/javadoc/arq/org/apache/jena/sparql/engine/main/OpExecutorFactory.html
>>
>>
>>
>> <https://jena.apache.org/documentation/javadoc/arq/org/apache/jena/sparql/engine/main/OpExecutorFactory.html>One
>> option is to read the Jena source code and try to understand what it
>> does, but it'd be nice if there are some documentation which I can
>> read first before I have to look at the source code.
>>
>>
>>
>> Thanks, Z
>>
>
> Hi,
>
> Without knowing more about your custom layer, it's hard to be very
> definite. You are probably better off looking at the code because when
> you come to integrate your work, you'll want to debug it and that means
> seeing how the internals work.
>
> For SPARQL processing, you don't (normally) need to implement Graph.
> Graph is for the RDF API.
>
> For SPARQL, it's based on DatasetGraph; there is a class hierarchy of
> classes covering many cases so usually you only need to plug into one of
> those. DatasetGraphTriplesQuads for example even if you have a
> triples-only storage system.
>
> SPARQL processing goes via OpExecutor. OpExecutor itself is a general
> execution of SPARQL algebra. See OpExecutorTDB1 for an example of an
> OpExecutor extended for a specific storage layer.
>
> OpExecutorTDB1 is the TDB specialization of OpExecutor to provide access
> to TDB-stored RDF; it only needs to provide the points where a SPARQL
> query actually touches the data: OpQuadPattern.
>
> Theer are few other there - OpBGP, OpGraph for the case of a TDB graph
> in a general mixed dataset (i.e a mix of storage layers).
>
> OpFilter is implemented by TDB to place filters within basic patterns
> because at that point, it is working with internal identifiers for RDF
> terms.
>
> Hope that helps,
> Andy
>
