@Andy, Let me know if you want me to add a bug in jira or if https://issues.apache.org/jira/browse/JENA-804 is sufficient.
On Fri, Feb 20, 2015 at 7:04 AM, Trevor Donaldson <[email protected]> wrote: > 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 >> >> >> >
