On 04/09/12 19:13, Stephen Allen wrote:
On Tue, Sep 4, 2012 at 2:21 AM, Andy Seaborne <[email protected]> wrote:
On 04/09/12 08:30, Dave Reynolds wrote:
On 03/09/12 18:33, Andy Seaborne wrote:
As part of wanting to tidy up and reduce the "core" of Jena, I'd like to
propose we
Remove BulkUpdateHandler interface
Migrate it's few useful operation to Graph.
Start to provide reification with "standard" only.
graph.QueryHandler only used to support reification.
+1 on both of these. They are annoying to code for, and as you say,
force batch triple changes into the client code where it doesn't
really belong.
How about removing TransactionHandler as well?
One step at a time!
TransactionHandler is not quite the right abstraction. It's begin() does
not indicate read or write intentions and this is reflected in the Model
transactional interface.
It might be possible to add promotable transactions in TDB but noting
everywhere a update can occur so read->write if necessary is not trivial.
If another transaction has committed, and the reader is looking at the
old DB state, then it's not possible (no locks on parts of the DB). So
at the point of promotion, the transaction may abort. Not a nice
programming paradigm. It's a side effect of having triples - what has
been updated where is not coupled to the application data model. Triple
level locking struck me as going to be very expensive for not a lot of
benefit.
My preference is to change Model.begin (i.e. Model implements
Transactional after transactional moved to somewhere general).
But that will cause certain users "some issues" :-)
Also make Dataset extend Transactional instead of copying the methods?
That's merely to isolate Dataset from the internal/graph level
Transactional interface - they ended up the same operations.
From experience, using abstractions at Graph and at Model (DatasetGraph
and Dataset) levels can lead to problems renaming things later. So it
has started as separate - deciding to merge later is possible.
Seems reasonable. I've used BulkUpdateHandler in client code on the
assumption that a store *might* optimize the updates but at least some
of those cases are, or could be made, add(Graph) calls.
Presumably this would this be a normal deprecate-then-remove-later cycle?
The Model operations remain -
Model.add(Statement[])
Model.add(StmtIterator iter)
Model.add(List<Statement> statements)
We could also consider simplification at the Model level- that wasn't on my
list.
It's interesting if you're using Graph level in an application - I'd like to
promote the Graph "SPI" as a more formally API after the cleaning up.
I tend to use the Graph SPI in my application as the objects are immutable.
I switch to which ever is most convenient ... but this will all help in
making the SPI more formally a public API. It's not far off that today.
Is that code still in use?
At the SPI level (Graph API), there is less of a contract on migration.
The reasoner does use the bulk update handler - but that's in-codebase so
that will just be cleaned up as part of the change. (Elsewhere in the main
code base most calls to getBulkUpdateHandler are ... implementations of
getBulkUpdateHandler over another graph!)
TDB has a bulk update handler to do removeAll and remove(s,p,o) without the
problems isomorphic to CCME.
SDB has a bulk update handler but the implementation of removeAll is in the
graph anyway.
In executing on this, I'd do at least a local deprecation cycle to track
down and migrate the current code without needing a local big bang.
Then at least a minor number version change to 2.10.0 would be good when the
change happens.
Observation on the deprecate-remove cycle: we know people don't upgrade
incrementally because they don't need to.
Another issue on the release pipeline is that some users are not testing the
development builds, only checking after a release. That's bad for them and
less than helpful for us. I don't want the effect of this to be making work
for the project. We make the deliverables in exactly the form we release in
every night so the only difference is location.
Andy
Dave
