Limit diff depth

[donhaldo]

Hello,
very goog library!

Is there a way to stop diffing objects to a definite depth?

I have to manage diff between hibernate envers revision objects, with lot of associations than i don't need to diff, primarly to avoid performance problems.
I'd like to stop diffing to first level attributes of each entities, but:

• I don't want to enumerate explicitly all the exclusion paths in configuration (there are a lot of them and may change in time...);
• I don't want to pollute my entities with @ObjectDiffProperty annotations, because i realized
  a generic revision comparison module and i'd like to be free to change diffing engine;

Is there a way to configure (o code an interface) of java-object-diff in order to stop differ works to first level nodes?

Many thanks in advance
Roberto

[SQiShER]

Hi Roberto,

do you think the proposed solution from #108 world work in your case? Instead of limiting the depth, you could just include the properties of your top level entities that don't go deeper into the object structure. Of course this would only work if you know the properties you want to include and they don't change constantly.

If that's not an option, it might be possible to add something like an InclusionStrategy (working title 😉) that can be registered in order to exclude certain nodes from the comparison. Let's say such a strategy would receive a DiffNode which provides access to the property type, name, annotations, etc. Would you be able to come up with some criteria based on which you would exclude a node? If not, what would you need to decide which property should be in- or excluded?

I'd prefer such a strategy over a simple depth limit, because it would be much more versatile and the definition of depth is probably not as trivial as it at first seems.

Cheers,
Daniel

[donhaldo]

Hi Daniel,
thank you for your reply!
I don't know in advance what properties to include, so the "Strategy" solution would be surely better for me: when comparing two revision of an entity of mine i need to know if each property is a base type or a regular object and, if it's an object, i need to know if it's a persistent one (i have a commont ancestor for all of them), so i will include for comparison only base types, but...

...for persistent object i'll also need a way to activate a "comparison rule" based only on persistent object identities, in order to avoid lazy initialization to fire.

So my problems are two, indeed: a way to discriminate what properties to compare based on strategies and a way to inject a "comparison rule" for persistent object.

Kind regards,
Roberto

[SQiShER]

There is already a ComparisonStrategy mechanism. But currently it can only be registered to nodes or classes. We probably need to find a way to register it globally or based on the common ancestor, in order to make it work.

Now for the property inclusion. Given an interface like this:

interface InclusionStrategy {
    boolean isIncluded(DiffNode node);
}

Now let's say every node will be passed to this strategy in order to determine whether it should be compared or not. Do you think, you'd be able to implement it in a way that solves your use-case? If not, what's missing?

[donhaldo]

Hi Daniel,
for property inclusion the InclusionStrategy will surely work for me, because from the node instance passed to isIncluded() i will be able to use property type and annotations to implement decisions for all objects involved in my use case.

For the "ComparisonStrategy" mechanism did you mean the Configuration withEqualsOnlyValueProviderMethod(Class, String) [and the other code that uses
NodeInspector.getEqualsOnlyValueProviderMethod(Node), NodeInspector.hasEqualsOnlyValueProviderMethod(Node)]?
I saw your comment you'd prefer to move those methods out of NodeInspector,
but in the meantime, changing the findEqualsOnlyValueProviderMethodForClass(Class) using
Class.isAssignableFrom() instead of equals will work without destructive side effects?

private ClassAndMethod findEqualsOnlyValueProviderMethodForClass(final Class<?> clazz)
{
for (final ClassAndMethod propertyPathEqualsOnValueProviderType : equalsOnlyValueProviderTypes)
{
if (propertyPathEqualsOnValueProviderType.getClazz().isAssignableFrom(clazz))
{
return propertyPathEqualsOnValueProviderType;
}
}
return null;
}

Cheers,
Roberto

[SQiShER]

Hi @donhaldo,

just a quick update: the master now contains an InclusionResolver mechanism, which should solve part of your problem.

As for the equals stuff: the code snippets that you posted look pretty old. Which version are you using? You should use 0.90 to get all the new features. Neither the NodeInspector, nor the Configuration classes even exist anymore. Maybe the new version already solves the other part of your problem.

Nonetheless, I'll work on a solution to allow users to register ComparisonStrategies globally, as this will surely be a pretty useful feature.

[donhaldo]

Hello Daniel,
i need to use maven to build my project, because i build customized release for different customers
so i use only library from maven repositories.
I was stick to 0.13.1 version due to the working in progress on the 0.90 release.
If it is stable i can switch to it: is there some doc or examples on converting old code to the new API?