graham,
Events and transaction isolation doesn't mix. Why being added, any
triples aren't visible outside the transaction; transactions can abort
resulting in no changes. So a kind of "within transaction" event might
make some sense (abort aside) but as a general concept it's a bit messy.
The best way to know 1-N have been added is to listen for the commit.
Use a DatasetGraphWrapper with the underlying DatasetGraph (or write a
DatasetWrapper - Dataset must be the only abstraction in ARQ without a
paired wrapper!).
Now you can add code before/after a commit to know when that point has
been reached.
Andy
https://afs.github.io/rdf-delta/ is a system for capturing changes. It
has a DatasetGraphChanges wheer you can add a listener and get all
adds/deletes and transaction boundaries. It is not part of Apache Jena.
It does work with it.
On 06/08/18 04:49, graham wrote:
Hi
The documentation for Jena event handling says the following: "In the
current design, listeners are not informed of transaction boundaries,
and all events are fed to listeners as soon as they happen".
This leads me to a question. I have a piece of code as follows:
database.begin(ReadWrite.WRITE);
model = storage.database.getDefaultModel();
add statement 1 to the model
add statement 2 to the model
...
add statement N to the model
database.commit();
storage.database.end();
I have another piece of code listening for changes in the database model.
How can that listening piece of code reliably detect that *all*
statements 1 through N have been added to the model, and hence the model
can be queried for whatever was added?
thanks
graham
