Re: [Bigdata-developers] problem with SPARQL update

[Jim B. <ba...@ne...>]

> On Mar 11, 2015, at 1:03 PM, Michael Schmidt <ms...@me...> wrote:
> 
> Jim,
> 
> first of all, I’d agree that the two queries are equivalent (unless I’m missing some typo here).
> 
> We’ve recently worked on improvements related to the evaluation of arbitrary length path operators (in your case: the transitive closure calculation over subClassOf), see http://trac.bigdata.com/ticket/1003. The fix there may help in terms of performance for both of your queries — as you may have noticed from previous discussions, we’re currently preparing the next release (planned for the end of the week), which will include this fix. We’d be happy to get your feedback whether this fixes the memory/performance of your query once the release is out.

After your message I tried the latest from the git master branch. It did change the performance of the update with the subquery: the memory increased more slowly, and although it did get close to maxing out, the update eventually completed, inserting 14,459,839 triples.


> Regarding the problem with the update having no effect: would you mind sharing your curl call? Is your request following the guidelines documented at http://wiki.bigdata.com/wiki/index.php/NanoSparqlServer#UPDATE_.28SPARQL_1.1_UPDATE.29?

I am submitting it like this:

curl -X POST --data-binary @materialize_subsumer.rq  --header "Content-Type:application/sparql-update" http://example.org/sparql

This doesn't match the example on the wiki, but I think it is correct according to the protocol. And I think it worked for other updates. I tried pasting my update query into the web dashboard and it also returned immediately with zero mutations. This curl command did work for the version containing the subquery.

So it does seem like there could be something funny going on with the first query. I don't have very much time to investigate this week but I will try to reproduce it with some other queries later.

Thank you!
Jim