On 25/11/12 20:07, Claude Warren wrote:
I care. I have been working on a security wrapper (dynamic proxy) and
I have to modify to match all the changes. Part of the security
design was to do it so that changes to the interfaces required changes
to the security classes since this forces security evaluation of new
methods.
However, I will manage to merge those in when necessary. Actually,
these changes will simplify the implementation.
+1
That's good to know.
I can't actually think of a use case for having different events for
different routes to adding triples except it batches events up into
arbitrary batches. I guess the mostly likely thing then is loop over the
cause so all that is saved is event call which is, I hope, small.
(A different design might have been a GraphWithEvents wrapper of the
basic Graph and let the next layer out decide ... more a stylistic
difference .. pro and cons.)
If you want to try up the new code, the branch has the new code. Just
change "GraphUtil.OldStyle" to false (tests will then fail - the tests
check for the different ways adds/deletes happen and I haven't changed
them pending this discussion).
Andy
-- Claude
On Sun, Nov 25, 2012 at 4:55 PM, Andy Seaborne <[email protected]> wrote:
I've had a go at removing all bulk update handler add and delete calls in
the (graph level) BulkUpdateHandler.
There is a branch "jena-core-simplified".
Graph acquires
removeAll()
remove(s,p,o) // Remove by pattern.
and the utility class GraphUtil has the implementations taken from
SimpleBulkUpdateHandler so code changes to callers has been remove the bulk
update call with a call to the equivalent static in GraphUtil.
1/
Currently, there isn't a Graph.add(Graph)
2/
ARP has been "de-bulked" - it sends triples off to the target graph of the
parser straight away; it used to batch them into units of 1000.
3/
There some issues arising around event callbacks.
There are various events, one for each way triples are added.
-- see GraphListener.
notifyAddArray( Graph g, Triple [] ts )
notifyAddTriple( Graph g, Triple t )
notifyAddList( Graph g, List<Triple> L )
notifyAddIterator( Graph g, List<Triple> it )
notifyAddIterator( Graph g, Iterator<Triple> it )
notifyAddGraph( Graph g, Graph added )
This seems rather complicated but it can't simply be removed now because all
this is reflected at the model level:
http://jena.apache.org/documentation/notes/event-handler-howto.html
The main way to get events is via ModelListenerAdapter which wires the
ModelChnagedListener level to the graph level.
And we don't believe there are any other implementations of Model (at least,
amongst people who upgrade).
If we switch to just two events,
notifyAddTriple
notifyDeleteTriple
will anyone notice or care?
In the branch currently, because currently all former bulk update operations
go via GraphUtil, the old-style events are generated and the tests all pass
unchanged.
Proposal - part 1:
Ask in [email protected] to see what, if any, use is make of model listeners.
Plan to make all changes either a single "added" or "removed" call.
If there is no evidence of use, remove extra calls now, and the next version
is 2.10.0.
Proposal - part 2:
Leave, deprecated, the call Graph.getBulkUpdateHandler and implementation
machinery of SimpleBulkUpdateHandler for one release, then remove it.
Andy
