I've downloaded hibernate extensions 2.1.
I was surprised when I read the changelog and saw that hbm2java no longer generated the equals()/hashcode() set for classes that have simple id's (e. g. no composite-id).
That meens that I have to use meta implement-equals attribute to enable the generation of the equals()/hashcode() set.
Is Middlegen using this attribute by default? I don't think it's reasonable to change my 150+ mapping files so that it can generate the set. It's bad for mantainance and error prone.

Sugestion:
Why not generate the pair in case of omitting the meta attribute? This way no work has to be done.

Any opinions?

http://www.hibernate.org/109.html explains why it was removed.

Thanks for the reply.
I've read the article. Even with these issues, I still prefer that hbm2java generates (if nothing is said) the pair for the id and generate the appropriate pair if the meta attribute is used.
This method doesn't help that much (I think) because you may not have the necessary property to use for the equals()/hashCode() pair rather than the id. What then?

Don't understand why this (big) change from the last version. I'm not willing to generate my 150+ mapping files and view one by one to see if it's necessary to use another property for the pair. Not much of a help from a generation tool.

It could continue to generate the pair according to the id (by default) and give the possibility to use the meta attribute to specify another property. That would have been the correct approach.


Sorry but I will have to stick with the version I'm using.


Any opinions?

Any opinions from the Hibernate team please?

Use the old version if you like broken POJOs, equals()/hashCode() should not use the identifier attribute.

Thanks for the reply.
But tell me, if you don't have a property that is unique by nature, then you only have the identifier to use for the pair generation, no?

It's not reasonable to alter the model and create a unique property for every entity to satisfy this issue, I think.

You don't have the identifier. You can't use it. It's not working like this.

This is not really a Hibernate problem.

Just so I'm not misunderstood, I agree with the fact that another property should be used besides the identifier to generate the pair.

My doubth has only to do with the fact that it's not using the identifier by default when we don't define the meta attribute.

The way the actual version works, we will have a lot of work defining the meta attributes before generating the POJO's.

This is quite sensible, because not generating equals hashCode creates less problems usually than using the id. So it makes sense to not generate by default.

You know that you only need equals/hashCode on your POJOs if you share objects in a collection (or compare them) outside of a Session scope? There are some other rules for special cases (composite element mappings and so on), but usually, you don't need it.

I agree with you, but in a big model 150+ tables, you will have a lot of entities that will be used in collections and a lot of these may not have a property that is unique in nature.
In these situations I will have to use a property for the pair so it will coherent with the collections specification, right?

All my equals()/hashCode() pairs are based in the identifier and I manage to live with it. :)

It only works for you because you probably never share objects _outside_ of a Session! You don't need a custom equals/hashCode in the first place.

i vote for a graphical "wizard" which propose the user which properties and strategy should be used for each POJO,
considering the different cases described in http://www.hibernate.org/109.html

The first step of the wizard would be: "do you share objects _outside_ of a Session?"
If user says no, hop wizars is finished, i'm ok to code this first step ;)))

ok i'm dreaming


Anthony

It would be easy for you to edit the velocity script in the Middlegen-Hibernate plugin and place the approprate new meta tags to force the generation of the hash-code etc. I will consider commiting a patch if its optional and default is not to generate the equals/hashcode methods.

Yes. Something like that. That would help not checking every entity.