You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Altmann, Michael" <Mi...@McKesson.com> on 2013/10/30 17:21:52 UTC
Should model.read emit addedStatements ?
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 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.
Thanks, Michael
Re: Should model.read emit addedStatements ?
Posted by 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
Re: Should model.read emit addedStatements ?
Posted by Andy Seaborne <an...@apache.org>.
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
>
>