Long or long for @Id?

Urmech · **Joined:** Thu Apr 14, 2005 10:39 am **Posts:** 115

Hi,

every example I have seen yet, uses the wrapper class as key. I would assume that the primitive type should be easier to handle for databases.

What are the advantages and disadvantages of both (wrapper class vs. primitive type) possibilities?

Does

Code:

@GeneratedValue(strategy = GenerationType.AUTO)

require an wrapper class?

If I have already overridden equals and hashcode to fulfil collections requirements, do I have to use the used properties (as compound key) in the database, or can I use a synthetic id?

A synthetic id would be easier, if equals and hascode will change in the future, but may cause problems. These problems may arise from the fact that equals regarding the id's is not the same as equals called on the given objects.

Thanks a lot in advance.

Greetings Michael

sanne.grinovero · **Posted:** Fri Apr 25, 2008 7:23 pm

Long may be null, long not;
Hibernate knows that if the PK is null it is a new entity that needs a new PK.

Quote:

If I have already overridden equals and hashcode to fulfil collections requirements, do I have to use the used properties (as compound key) in the database, or can I use a synthetic id?

Much has been written on this topic, I would suggest you to read one of the Hibernate books as there are many strategies and implications you should be aware of.

Urmech · **Joined:** Thu Apr 14, 2005 10:39 am **Posts:** 115

Hi Sanne,

s.grinovero wrote:

Long may be null, long not;
Hibernate knows that if the PK is null it is a new entity that needs a new PK.

thanks, I haven't taught about detecting unset keys before. Even zero may be used for long also, if the generator wouldn't use the zero value.

Quote:

If I have already overridden equals and hashcode to fulfil collections requirements, do I have to use the used properties (as compound key) in the database, or can I use a synthetic id?

Much has been written on this topic, I would suggest you to read one of the Hibernate books as there are many strategies and implications you should be aware of.

Do you know where I can find a short summary?

Most important is for me, if overridden equals an hashcode forces a natural key, or not.

But if I want to have a database wide unique (according to equals) instance and not only application wide (e.g. cause of Set restrictions) unique instance, I have to use the natural key, or?

Thanks.

Greetings Michael

sanne.grinovero · **Posted:** Mon Apr 28, 2008 5:00 am

Hi,

Quote:

Even zero may be used for long also, if the generator wouldn't use the zero value.

Yes, but what would happen if you created two new entities and add them to the session? they would have the same PK, so hibernate may think they are representing the same "DB row"... So you anyway have to handle the special value in a special mode, using null seems the most intuitive solution as a marker value. You could actually use the "0" strategy using "unsaved-value" (search for it in the core reference docs).
I (personally) use "long" for most "lookup" and "type" entities, as I don't ever persist new entities of this types, so it's also a reminder for developers.

Quote:

Do you know where I can find a short summary?

here is some material:
http://www.hibernate.org/109.html
http://www.hibernate.org/hib_docs/reference/en/html/persistent-classes.html

regards,