On 14/04/16 13:43, Alexandra Kokkinaki wrote:
Thanks Andy, so you are suggesting to break the updates (deletions and
insertions) in smaller requests to avoid any memory issues. I suppose that
we will make daily updates so that our triple store is up to date, which
will probably result some hundreds of triples.
Hundreds - no worries.
Just keep the batch size of a single request below a few million (and
tweak the heap up a bit if you are doing million+ updates at one time).
Do not increase the heap regardless TBD uses non-heap space so more heap
is slower.
I have seen the commit command but not the rollback. Is there any safety
net if something goes wrong during the update procedure to rollback?
Are there any nice examples about "TDB transactions" that I could start
looking at?
In Fuseki, one HTTP request = one transaction. It aborts if the update
fails (e.g. bad request, syntax error).
What there isn't yet is begin-request-request-request-commit.
If you are dealing with hundred of triples, the way to approach is to
build up a set of all the changes you want, build a SPARQL update and do
it all at once. It will all happen or none happen.
You can not update a database using the TDB tools when Fuseki is using it.
Andy
