Re: Should model.read emit addedStatements ?

[Claude Warren <cl...@xenei.com>]

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 <an...@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 web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren