incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Jena and PostGIS (à la LARQ)
Date Tue, 13 Sep 2011 16:52:28 GMT

On 13/09/11 17:45, Paolo Castagna wrote:
> Andy Seaborne wrote:
>> On 13/09/11 16:14, Alexander Dutton wrote:
>>> Does Fuseki/TDB currently fire off some kind of signal when updates
>>> happen?
>> Handling of events isn't consistent yet.
>> Each GraphStore sees startRequest()/finishRequest() around a SPARQL
>> Update. That should be roughly what you are looking for, I guess.
>> There isn't an event down to the level of each quad added or removed.
> This might be easier for developers (since they don't need to parse
> the SPARQL Update request).
> But, maybe there is a good reason why there isn't an event down to the
> level of each quad added|removed. Let me guess: performances? :-)

Not some much this time - here, it's consistency of the data.

What does it mean to signal a quad added or removed without context? 
e.g. for geo, it may take several triples to change the dataset from one 
application-consistent view to another.

Context matters here and just seeing a triple/quad change is a bit 
useless.  What if you want to see a set of changes ... like one complete 

>> Now is a good time to work out the details of what's wanted. The
>> original jena events mechanism works well but places the events on an
>> object, so only objects supporting the event interface participate.
>> Makes global or general events unnatural as well.
> Yep.
>  From a LARQ or similar point of view (i.e. third party custom indexes)
> it would be extremely easy to be able to be notified for each quad
> added or removed.
> This way and external index can be kept up-to-date as data changes.
> Often, there are little changes and it's a waste of time/resources
> (and it require manual intervention or automated scripts) to re-index
> everything just because a small percentage of data has changed.

An example of wanting set of changes.

>> The package org.openjena.atlas.event (in ARQ) is my attempt to retain
>> the light weigh event mechanism but decouple it from an event
>> interface. You can send events relating to objects without the objects
>> participation.
> I'll have a look (and see if I can use that in LARQ).

I suspect we need a system-wide design - e.g. events on transactions. 
And transactions give a consistency point as well.


> Thanks,
> Paolo
>> Andy

View raw message