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
update.
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.
Andy
Thanks,
Paolo
Andy
