Guys, It would make our lives a lot more painful if you don't follow a deprecate-then-remove-later cycle for the BulkUpdateHandler interface. We have client code programmed against this and in our db2 implementation there is also a custom implementation (for obvious reasons - that was probably the original motivation for the API in the first place). If you remove (or even move) the operations in a big bang, we can't gracefully adopt.
Btw, we *always* test unreleased snapshots as much as possible. An absence of a deprecate-then-remove-later cycle would make this more difficult. Also, there are many separate dependant groups in our organization that we cannot possibly ever handle big bang changes. Finally, this brings me to a question I have posed before. Jena, so far, has not been very clear on what is public API and what is not. I read here that the Graph API sits at the SPI level but we have countless clients which program against this level as well since it is readily available and easy to reach. There is no indication anywhere (e.g. in the javadoc or packaging) that these APIs are not public. The first step towards improving this situation is to declare, perhaps at the package level, what APIs are public and what not so clients know what kind of contract they get themselves into thanks Simon From: Dave Reynolds <[email protected]> To: [email protected] Date: 09/04/2012 05:46 AM Subject: Re: Evolution: BulkUpdateHandler / Reification / QueryHandler On 04/09/12 10:21, Andy Seaborne 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. >> >> 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. > > Is that code still in use? I thought it was but having now checked then no, none of my currently in-use projects use BulkUpdateHandler directly. > At the SPI level (Graph API), there is less of a contract on migration. Agreed. I'm fine with going ahead with the change. > 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. Sure. Dave
