My meta use-in-equals is being ignored in a subclass. Is this expected? I'm using hibernate tools 3.2.0.beta9a.



The resulting Bug class has an equals method and hashcode() , the resulting SubBug has neither.

if i remember correctly the you should get a warning about it being ignored because if not it would result in asymmetric equals which is bad.

It never amazes me how hard equals() is! After some study, I see the problem. Fortunately, there is a solution...

If you think in terms of the table-per-class inheritance model, I want the discriminator column in the equivalence relation which comparing a fixed projection of the table onto a set of columns. Equality after projection is always an equivalence relation, so this must work. In my Bug, SubBug example this set of fields is {discriminator, name, subname}.

The way hibernate implements equals uses instanceof instead of getClass() comparison.. This is precisely the difference between including or not including the discriminator column in the table projection. Interestingly, eclipse generates equals() methods that always use the getClass() comparison. Neither is right or wrong, they simply define different equalivalence relations. Depending on what I'm modelling I will need both at different times.

The example Bug.equals method from hibernate:


Compare to what eclipse does via Source->Generate hashcode() and Equals() for Bug.equals :
and then SubBug.equals

Note the gotcha with the eclipse way is that even if I cast I can never have a Bug equal a SubBug.

The last assertion is because bug2.equals calls SubBug.equals (not Bug.equals!) and the getClass() returns SubBug, while obj.getClass() returns Bug, so it drops out. This seems really strange unless you think about it in terms of the database table and projecting onto {discriminator, name, subname}. Casting doesn't change the getClass() value, nor the discriminator column.

If you don't include the discriminator column in the projection, but do use a column that only exists in a subtype, you get into trouble when you cast up, because the parent class can't do the projection you really want as it doesn't have access to all the fields. The child can, so you get different results. Hence the violation of symmetry.

The implementation mechanism to allow both seems obvious: allow use-in-equals to apply to the descriminator too. Then use getClass comparison like eclipse if it's set. Otherwise use instanceof as you already do.[/code]

I don't think calling .getClass() will work properly with proxies.

Good point. So use HibernateProxyHelper.getClassWithoutInitalizingProxy() instead.

Better yet, call an equality helper utility that can map .getClass() to the proper discriminator value. A simple implementation would just resolve proxies, but a complex one might give me more control over which branches of the inheritance hierarchy I consider equalivalent.

For example, suppose I had a Person class with a Man and Woman subclass and each of these had lots of subtypes. Maybe I want equals to require the same gender by ascending until I hit Man or Woman (or Person, I suppose).

If I had a proxy for a Father object (a sublcass of Man), then I would call something like: equalityHelper.getEquivalenceClass(fatherProxy) and get Man.class. This could be implemented like this


A class could be put in the equivalenceMap for it's root class if it is the root mapping class, or if it's so annotated with an appropriate use-in-equals meta tag on its discriminator.

Using an EqualityHelper could simplify the generation of equality methods and make it powerful and extensible. The hbm.xml file could be used to state which equality helper implementation to use if you wanted to override the default.

having hibernate specific code in pojo's would be bad...

It's also bad to introduce hibernate specific proxies underneath the pojos when that interferes in subtle ways with common and useful ways of constructing equals methods. If the choice is truly between the not using the equals method you need and hibernate free pojos is there no need for choice?

What would you suggest as the proxy-safe way to require a gender match in a class model using Man and Woman subclasses of the Person class?

To remove the hibernate dependencies from the generated domain model, you could generate the artifacts I was speaking of in a user specified package. One solutione would use a generated EqualityHelper interface and EqualityHelperFactory class, both referenced from the pojo equals method, and then either generic standard EqualityHelper implementations with the factory using generated code or configuration to get the right pojo specific behavior or, alternatively, a domain model specific implementation for each mapped class. This option adds a little complexity, so maybe it's a three way choice:

a) simple: less fine grained control over equals methods (status quo)
b) coupled: fine grained control with pojos that depend on hibernate
c) complex: fine grained control without pojo-hibernate coupling

Tough decision...