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? Also make Dataset extend Transactional instead of copying the methods? >> >> 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. > 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 >> >
