I am using sparql to do
INSERT DATA{
GRAPH <GRAPH_NAME> {
<uri> my:id val
.....
reified statement
}
}
Deleting using
WITH <GRAPH_NAME>
DELETE {<uri> my:id ?o}
WHERE {
<uri> my:id ?o
}
WITH <GRAPH_NAME>
DELETE {?s ?p ?o}
WHERE {
?s rdf:subject <uri> .
?s rdf:predicate my:id .
?s ?p ?o
}
I am batching these up 50 at a time and using
UpdateExecutionFactory.createRemote. Doing it this way the database grows
at an expected rate. I would have loved to use the model api but it is
unusable with the size issue with putModel.
On Fri, Feb 20, 2015 at 6:53 AM, Andy Seaborne <[email protected]> wrote:
> On 19/02/15 12:42, Trevor Donaldson wrote:
>
>> Thanks Andy for your feedback. I realized I can not use
>> datasetAccessor.putModel or datasetAccessor.add. After much trial and
>> error
>> I have determined that the following allocates space (often doubling the
>> database size) and never releases it.
>>
>> for(int i=0; i<1000;i++){
>> Resource s = ResourceFactory.createResource("http://example.org/A/
>> "+i);
>> Property p = ResourceFactory.createProperty("urn:my:id");
>> RDFNode o = ResourceFactory.createTypedLiteral(i);
>>
>> Statement stmt = model.createStatement(s,p,o);
>> model.add(stmt);
>> }
>>
>> datasetAccessor.putModel(GRAPH_NAME,model); //doesn't matter if I
>> use
>> this or add(GRAPH_NAME,model)
>>
>>
>> One thing I have noticed is that if I use sparql inserts and deletes the
>> database size does not grow exponentially. I think the sparql query route
>> is probably more prone to error but since it seems more reliable as far as
>> database growth, I will go that route.
>>
>
> What are the inserts and deletes you are doing?
>
> Something for use to look at. I would have through that putModel and an
> equivalent SPARQL Update would cause very similar pace usage despite being
> different routes through the code. Maybe the putModel route is wrong in
> some way.
>
> But first data point is whether the SPARQL Updates are indeed sufficiently
> equivalent.
>
> Andy
>
>
>
