In addition to the problem indicated in http://forum.hibernate.org/viewtopic.php?t=930056 (for which I currently have no solution), I have another issue regarding hbm2java.

My problem is I have a number of classes that get created and manipulated before being persisted: some of those manipulations involve putting them in sets, but here is the problem.

The default hashcode implementation provided by hbm2java uses jakarta commons lang HashcodeBuilder and EqualsBuilder, and here's the problem: if nothing else has been specified, the builders use the id property to calculate hashcode and equality.

The problem is that when those classes have just been created, they have no id, as it will be generated when persisting them: hashcodebuilder and equalsbuilder both return the same value for this case.

My question is: shouldn't the default implementation resort to Object.hashcode and Object.equals when the fields submitted to the builders are all null?

After looking a bit at the code I have clearer ideas. What I meant is: shouldn't something like the following be added to "BasicRenderer.doEqualsAndHashcode"?

writer.print(" if ( ");
for (Iterator fields = classMapping.getFields().iterator(); fields.hasNext();) {
Field field = (Field) fields.next();
if ( field.isIdentifier() ) {
writer.print( field.getGetterSignature() + " == null" );
}
if ( fields.hasNext() ) writer.print( " && " );
}
writer.println(" ) {");
writer.println(" return super.equals( castOther )");
writer.println(" }");

and the same for hashcode: this way when the objects have not yet been persisted, one could add them to sets being sure they will be treated as different objects and will not overwrite each other in the underlying map.[/code]

Code repost. :)

Well of course with the new 2.1 tools BasicRenderer version things are a little bit trickier but the same ideas apply as well: I could as well implement my own renderer, but I'd like to know if is there some drawback in the approach which resorts to Object class behaviour when all the fields are null.

Answer to self: that solution is maybe feasible, and it basically turns to implement a Renderer which extends BasicRenderer and overwrites the toEqualsAndHashCode method, then use the config attribute in hbm2java ant task to point to a config.xml file that indicates that the tool should use that config instead of the default hardcoded one.

Although, reading http://hibernate.org/109.html suggests that the best way to go is identifying a set of fields that can be used in order to determine object identity in a primary-key independent fashion, and use those fields in hashcode and equals.

Thanks anyway (for the docs and the pointer to the 109.html embedded in BasicRenderer's code! ;) ).

See also: http://forum.hibernate.org/viewtopic.ph ... 78#2191778 :)))