Re: delete insert where

Thanks Andy! I guess then it may be somewhere in my implementation (since I implement OpExecutor interface) That SELECT query will return ?old and ?new are referring to a same node. From: Andy Seaborne Sent: Wednesday, March 16, 2016 11:45 AM To: users@je

Re: delete insert where

On 16/03/16 19:47, Zen 98052 wrote: I take it back, OpExecutor only applies to the WHERE clause, and in this example nothing much being done from my custom code. This is the actual Sparql query (my previous example was too simplified): DELETE { ?snapshotOld

Re: delete insert where

I take it back, OpExecutor only applies to the WHERE clause, and in this example nothing much being done from my custom code. This is the actual Sparql query (my previous example was too simplified): DELETE { ?snapshotOld . } INSERT { ?snapsho

Re: Fuseki server: many data services or many fuseki installations?

Hi, t will depend on usage patterns. 2* 500 million isn't unreasonable but validating with your expected usage is essential. The critical factors are the usage patterns and the hardware available. Number of queries, query complexity, number of updates, all matter. RAM is good (which is true

Re: Fuseki + Lucene special characters.

Hi Mark! Thanks for pointing this out. This seems to be a bug/feature of the jena-text module. It is not directly related to Fuseki (which is really the web server module), but Fuseki includes jena-text. Your interpretation of what is happening seems correct to me. Do you have a suggestion o

Re: Loading RDF XML while Fuseki is running

> No idea? I need to update data to either running database or make > a new db. (to a message 3 days ago ...) "this does not work" is a bit minimal. What does work? Other s-* commands? Other files? I'd guess that ".xml" is not recognized as RDF. It's not the right file extension. The MIME ty

Fuseki server: many data services or many fuseki installations?

Hi, after researching on TDB performance with Big Data, I would still like to know: We have one fuseki server exposing 2 sparql endpoints (2million triples each) as data services. We are planning to add one more, but with Big data >500Million triples - For big data is it better to use many ins

Re: arq:spillToDiskThreshold issue

I don't think having enough memory is a working solution because we will need the big amount of memory only on rare occasions, so most of the time the memory will be "wasted". During my investigation I came up with 2 causes of the problem: 1. The close method of org.apache.jena.tdb.base.file.B

Re: arq:spillToDiskThreshold issue

On 18/03/16 09:16, Dominique Vandensteen wrote: Hi, I'm having problems handling "big" graphs (50M to 100M triples at current stage) in my fuseki servers using sparql. The 2 actions I need todo are "DROP GRAPH <...>" and "MOVE <...> TO <...>". Doing these action with these graphs I get OutOfMemor

Re: Persisting named graphs in TDB with jena-fuseki

https://issues.apache.org/jira/browse/JENA-1122 (resolved) looks relevant here. It is not in any release, only in development builds. It should support <#service1> and <#service2> having the same inference dataset. The case of a shared TDB databases does (should) work in a release but not

Re: delete insert where

Works for me. What's SELECT * { ?new rdf:m "blah" . OPTIONAL { ?old rdf:b rdf:thing . } } On 16/03/16 15:18, Zen 98052 wrote: Hi, I am trying to understand how DELETE/INSERT WHERE query is working since I see unexpected behavior. According to http://www.w3.org/TR/sparq

arq:spillToDiskThreshold issue

Hi, I'm having problems handling "big" graphs (50M to 100M triples at current stage) in my fuseki servers using sparql. The 2 actions I need todo are "DROP GRAPH <...>" and "MOVE <...> TO <...>". Doing these action with these graphs I get OutOfMemory errors. Some investigation pionted me to http://

Fuseki + Lucene special characters.

Hi Jena Users. We've been experiencing some peculiar behaviour with Jena/Fuseki and Lucene - particularly, but not entirely, around special characters. We are currently running Fuseki 2.3.0, which seems to include Lucene 4.9.1, as far as we can tell. Using the query: PREFIX text: