jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: svn commit: r1298002 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/mk/store/StoredNodeAsState.java
Date Wed, 07 Mar 2012 23:47:50 GMT


> On Wed, Mar 7, 2012 at 9:45 PM, Michael Dürig<michid@gmail.com>  wrote:
>> Regarding equals in the abstract base classes: I'd make the equals methods
>> in the abstract base classes final.
>
> No, the current non-final implementation is by design.
>
> See the followup patch I attached to OAK-3 for what I'm aiming at
> here. Basically I want to decouple the task of diffing node states
> from the underlying storage model (so far the diff() method has been
> an integral part of the .mk.model.Node interface).
>
> To do that efficiently, we need a fast way to compare potentially huge
> subtrees for equality. The underlying storage model can do that for
> example when the states point to the same storage location or have the
> same content hash, which is why they should be able to override the
> equals() method. Otherwise an equals() check could end up traversing
> the entire subtree.

Ok makes sense.

>> Overriding them in a concrete subclass will most likely break symmetry.
>
> If it does, it breaks the API contract and should be fixed.

Right. I should have read the Javadoc ;-) However, I'd make it more 
explicit there, that sub classes must not refine equality (i.e. take 
into account values of other fields). This will in almost any case lead 
to a broken contract. For example (emphasis added): "Two property states 
are considered equal if *and only if* both their names and encoded 
values match."

Michael

Mime
View raw message