On 11/05/14 00:25, Stu Btwotwo wrote:


As far as I know, there is no existing mechanism for a program hosting a
TDB Dataset to know when its contained graphs have been modified by a
SPARQL Update request.   In Jena 2.10.1, the ModelChangedListener
mechanism does not seem to
be notified (ever) when underlying graphs are modified by a SPARQL
Update request.

You are correct in the last part - changes not going via the model don't get notified.

I can  post some test code I used to determine that, if
anyone is
interested.   However, ModelChangedListener does work (in Jena 2.10.1)
when the changes originate in the Model-Statement API or a  LOAD request.

Is the situation any different in Jena 2.11?  Are any other relevant
changes
planned for future versions?

See DatasetGraphMonitor.

You will need to get the DatasetGraph, wrap it in a DatasetGraphMonitor and put back the Dataset layer.

Then the associated DatasetChanges is called on every add/delete of a quad and you can build any kind of notification framework on top of that.

Or just a DatasetGraphWrapper (which is DatasetChanges is using) what and catch the add/delete of quads.

Please let us know how this goes; it's relatively new.

        Andy

For starters I would like to at get a callback telling me that a
particular TDB graph (indicated by name) was modified (by whatever
mechanism:  SPARQL Update, Model-Statement API, LOAD request).
This notification would preferably occur at the time of transaction
commit, and would not necessarily need to supply the actual changeset
triples (although having those available would of course be useful).

Getting all the modified graph-Names for a transaction in one callback
would be
helpful.

Or, if we could merely ask a Dataset(-transaction) for its modified
graphNames, before the transaction commits, that would work as well.

In whatever form, even if the feature is not transactionally consistent,
if there is some way to know that a graph was written (but perhaps not
yet committed) during an update, that would be a step forward for us.

Assuming there is not a nice API method that I have missed, is there a
clean extension point where I could bind in a subclass (during Dataset
assembly, perhaps) that would accomplish this kind of notification at
the per-graph level?

Stu


Reply via email to