in new_tests the model Contract test (
https://svn.apache.org/repos/asf/jena/Experimental/new-test/src/test/java/com/hp/hpl/jena/rdf/model/ModelContractTests.java)
is:
@Test
public void testRead_InputStream_String_String() throws Exception {
InputStream is = getInputStream(TestReaders.nt);
String lang = N-TRIPLE;
model.register(SL);
txnBegin(model);
assertSame(read() must return model, model,
model.read(is, foo:/bar/, lang));
txnCommit(model);
assertTrue(
Start graph missing,
SL.hasStart(Arrays.asList(new Object[] {
someEvent, model,
GraphEvents.startRead })));
assertTrue(
end graph missing,
SL.hasEnd(Arrays.asList(new Object[] {
someEvent, model,
GraphEvents.finishRead })));
// FIXME add tests for converting relative to base.
// assertTrue( Can not find resolved relative statement,
// model.contains( resource( foo:/bar/e), property(
foo:/bar/p5)));
is = getInputStream(TestReaders.nt);
txnBegin(model);
model.removeAll();
SL.clear();
assertSame(read() must return model, model,
model.read(is, null, lang));
txnCommit(model);
assertTrue(
Start graph missing,
SL.hasStart(Arrays.asList(new Object[] {
someEvent, model,
GraphEvents.startRead })));
assertTrue(
end graph missing,
SL.hasEnd(Arrays.asList(new Object[] {
someEvent, model,
GraphEvents.finishRead })));
// FIXME add tests for relative .
// Resource s = ResourceFactory.createProperty( null, e
// ).asResource();
// Property p = ResourceFactory.createProperty( null, p5);
// assertTrue( Can not find relative statement,
model.contains( s, p
// ));
}
So the contract says the model must emit a GraphEvents.startRead and a
GraphEvents.finishRead. Other than that the contents of the events
between the start and finish are not defined, so either a single
addedStatements or multiple addedStatement are acceptable.
Claude
On Thu, Oct 31, 2013 at 3:51 PM, Andy Seaborne a...@apache.org wrote:
On 30/10/13 16:21, Altmann, Michael wrote:
I am trying to upgrade our application from Jen 2.7.3 to 2.11.0 It
appears that in Jena 2.7.3 model.read(stream, null, RDF/XML) fired
a single ModelChangedListener.**addedStatements
IIRC not necessarily a single call - won't it be once per 1000 statements
or so? ARP batches updates and send them in clumps to the model. Each
clump caused addedStatements(Statement[])
The other parsers have never done this.
whereas
model.read(stream, null, TTL) fired separate addedStatement
events.
Now in 2.11.0, both types of load emit only
ModelChangedListener.**addedStatement events.
Was this change intentional? I don't see anything in the issues.
Not so much intentional but it is a consequence of unifying the handling
of parsing.
Rather than leave the contract to the particular reader (hence different
behaviour in 2.7.3 for RDF/XML and TTL, compared to 2.11.0). And its not
part of any contract which of the addedStatements calls gets called and how.
There is a nesting GraphEvents.startRead , GraphEvents.finishRead pair
around each parser run. That puts the event boundaries on something more
logical and less implementation sensitive. (get via the graph level
handler)
This is something worth sorting out - its the bulkupdate issue in
disguise. Putting in logical boundaries for changes looks like the right
thing to do, and reflect the fact that deletion is not like addition in
reverse.
(does anything need bulk delete signalling not by pattern? mixes of
adds/deletes over and above add/delete notification of each change?).
Andy
Thanks, Michael
--
I like: Like Like - The likeliest place on the webhttp://like-like.xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
