Notification of Graph Changes by ARQ+TDB, during or after SPARQL Update

[Stu Btwotwo <st...@appstract.com>]

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.  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?

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

Re: Notification of Graph Changes by ARQ+TDB, during or after SPARQL Update

[Andy Seaborne <an...@apache.org>]

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
>