On Thu, Apr 3, 2014 at 10:12 AM, Chris Dollin
<[email protected]>wrote:

> On Thursday, April 03, 2014 09:51:31 AM Rob Hall wrote:
> > In order to provide some basic MVCC & transaction functionality for
> > in-memory models, I'm writing an extension
> > to com.hp.hpl.jena.graph.impl.GraphBase.
> >
> > The core functionality is complete, and right now I am writing a means by
> > which to defer listener updates until a commit (so that updates reflect
> the
> > actual changes to the underlying graph).
> >
> > This requires overriding GraphBase#add(Triple) and
> GraphBase#delete(Triple)
> > rather than only GraphBase#performAdd(Triple) or
> > GraphBase#performDelete(Triple), yet GraphBase#delete(Triple) has been
> > declared final.
>
> Yes, deliberately. Just override performDelete and notifyDelete. delete is
> final so you can't forget to call checkOpen and notifyDelete.
>

That's exactly the problem. In order to defer listener updates until after
a commit,
I must enforce that notifyDelete is not called until I want it to be. It
may be the case
that is more appropriate for me to implement this graph type from scratch
in a
similar vein as WrappedGraph or GraphBase2.

Inversely, if GraphBase#delete(Triple) does not have the final declaration
removed,
it would make sense to me to declare GraphBase#add(Triple) final so that
the
implementation enforces this on both methods.

In a more philosophical note, it would be nice if there would be a warning
issued
for overriding #add or #delete (perhaps through a custom annotation) rather
than
barring users from doing it altogether. I agree that a user's first
instinct will be
to override #add/#delete rather than #performAdd/#performDelete, and that it
should be discouraged.

>From a workaround perspective, perhaps it would be more elegant to link a
custom event manager to the custom transaction manager that my
implementation
currently uses rather than override #add/#delete. That being said, the
declaration
of a final #delete doesn't appear to be much of a deal breaker for me
anymore.

Cheers.

Reply via email to