Virtuoso over sesame 4 SPARQLRepository, @NamedGraph problem on remove()

[Riccardo Santoro]

Hello Mike,

While somebody else is investigating a possible bug with the virtuoso sesame4 driver, I switched to using a sesame SPARQLRepository connecting to the Virtuoso instance and therefore working through http. In this case the Date properties are persisted and retrieved correctly, which confirms that the problem is the driver.

A new problem has emerged: Virtuoso demands that a DELETE sparql query specifies the graph. I annotated therefore the POJOs with a NamedGraphType.Static and provided the value.

The annotation is read and processed correctly on an instance of such a POJO created explicitly by calling its constructor. I know because the insert does add the data to the specified graph.

However, an instance returned by a find() is created dynamically by the RDFGenerator and this one does not contain the annotation: this causes a remove() on this returned instance to fail at the virtuoso server, which expects the graph to be supplied in the delete sparql query.

Also the rollback() fails on Virtuoso if a begin() was not previously called. In my implementation of the DataSrouce I have therefore UNcommented the instructions on the begin() method which I copied from the Empire distribution sesame RepositoryDataSource. This works at least in my test case.

I wonder why the Empire distribution sesame  RepositoryDataSource's begin method is commented out, except for the assertConnection instruction.

I know that virtuoso support in Empire is 'for later', so I won't mind if you can't spend time on this: a brief answer would be nonetheless greatly appreciated.

[Michael Grove]

On Wed, Apr 27, 2016 at 11:17 AM, Riccardo Santoro <r.sa...@2thecloud.biz> wrote:

Hello Mike,

While somebody else is investigating a possible bug with the virtuoso sesame4 driver, I switched to using a sesame SPARQLRepository connecting to the Virtuoso instance and therefore working through http. In this case the Date properties are persisted and retrieved correctly, which confirms that the problem is the driver.

Ok, good to know.

 

A new problem has emerged: Virtuoso demands that a DELETE sparql query specifies the graph. I annotated therefore the POJOs with a NamedGraphType.Static and provided the value.

The annotation is read and processed correctly on an instance of such a POJO created explicitly by calling its constructor. I know because the insert does add the data to the specified graph.

However, an instance returned by a find() is created dynamically by the RDFGenerator and this one does not contain the annotation: this causes a remove() on this returned instance to fail at the virtuoso server, which expects the graph to be supplied in the delete sparql query.

That's probably related to the fact that EmpireUtil#getNamedGraph & #hasNamedGraphSpecified do not check superclasses for the annotation.

 

Also the rollback() fails on Virtuoso if a begin() was not previously called. In my implementation of the DataSrouce I have therefore UNcommented the instructions on the begin() method which I copied from the Empire distribution sesame RepositoryDataSource. This works at least in my test case.

I wonder why the Empire distribution sesame  RepositoryDataSource's begin method is commented out, except for the assertConnection instruction.

As I recall, that's what was required for the Sesame API.

 

I know that virtuoso support in Empire is 'for later', so I won't mind if you can't spend time on this: a brief answer would be nonetheless greatly appreciated.

It's safe to say at this point I'm not going to implement support for virtuoso.

Cheers,

Mike

 

--
You received this message because you are subscribed to the Google Groups "Empire" group.
To unsubscribe from this group and stop receiving emails from it, send an email to empire-rdf+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Riccardo Santoro]

Fair enough, I implemented virtuoso-specific injected DataSource remove() methods supplying the required context and all is well for my prototype app.

I was just wondering if annotations at the superclass level should not be considered in the general case, for example in the non-virtuoso specific case where a RdfClass is a subclass of another, which would also probaby require the generation of a <aSubclassIRI> <rdfs:subClassOf> <itsSuperClassIRI> triple in the model.

Thanks a lot!

[Michael Grove]

On Thu, Apr 28, 2016 at 3:15 AM, Riccardo Santoro <r.sa...@2thecloud.biz> wrote:

Fair enough, I implemented virtuoso-specific injected DataSource remove() methods supplying the required context and all is well for my prototype app.

I was just wondering if annotations at the superclass level should not be considered in the general case,

They should, but require the MappedSuperclass annotation.

Cheers,

Mike

 

for example in the non-virtuoso specific case where a RdfClass is a subclass of another, which would also probaby require the generation of a <aSubclassIRI> <rdfs:subClassOf> <itsSuperClassIRI> triple in the model.

Thanks a lot!

On Wednesday, April 27, 2016 at 5:17:45 PM UTC+2, Riccardo Santoro wrote:

Hello Mike,

While somebody else is investigating a possible bug with the virtuoso sesame4 driver, I switched to using a sesame SPARQLRepository connecting to the Virtuoso instance and therefore working through http. In this case the Date properties are persisted and retrieved correctly, which confirms that the problem is the driver.

A new problem has emerged: Virtuoso demands that a DELETE sparql query specifies the graph. I annotated therefore the POJOs with a NamedGraphType.Static and provided the value.

The annotation is read and processed correctly on an instance of such a POJO created explicitly by calling its constructor. I know because the insert does add the data to the specified graph.

However, an instance returned by a find() is created dynamically by the RDFGenerator and this one does not contain the annotation: this causes a remove() on this returned instance to fail at the virtuoso server, which expects the graph to be supplied in the delete sparql query.

Also the rollback() fails on Virtuoso if a begin() was not previously called. In my implementation of the DataSrouce I have therefore UNcommented the instructions on the begin() method which I copied from the Empire distribution sesame RepositoryDataSource. This works at least in my test case.

I wonder why the Empire distribution sesame  RepositoryDataSource's begin method is commented out, except for the assertConnection instruction.

I know that virtuoso support in Empire is 'for later', so I won't mind if you can't spend time on this: a brief answer would be nonetheless greatly appreciated.

--