On Wed, Sep 5, 2012 at 3:25 AM, Andy Seaborne <[email protected]> wrote: > 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).
Agreed. I think having the user specify READ or WRITE at transaction begin() is the right way to go. Promoting transactions is fraught with all the issues you brought up. > > 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 >>>> >>> >
