Just out of curiousity:
The doc says a Long ID is better than the primitive long, but doesn't elaborate. My guess is Long performs better since Hibernate boxes primitives to track state internally, so you avoid extra object creation when using Long in the object itself.

Thoughts? :)

Jen

I don't know if this is why, but...

Hibernate has to have a way to distinguish a detached object from a transient object. By default, Hibernate recognizes an object whose id is null as transient. By using a class type for the id you avoid the slight complexification of having to supply an 'unsaved-value' attribute on the <id> mapping, as you would have to do when using a non-nullable, primitive type for the id.

HTH,
—ml—

Object types over primitives are usually preferred in relational mapping because they can represent the "NULL" value of a column, while primitives can't.

If you had a integer column which is defined NOT NULL on the db, you could use primitives though. But I think it's better to standardize on object types.

Giulio

I see, thanks guys.

Since a primary key can never be <null>, the primitive seems perfectly fine, but are therer other reasons?

Jen

The other answer on this thread is off-the mark IMHO, but be that as it may... try thinking "identifier" instead of "primary key". That is, consider, rather than a table row, an instance of the class (i.e. a live object). If the id property is of a class type, then the value of that property can be null — and indeed will be null in the case of a newly-created object that has never been persisted to the database. This corresponds to the condition of having no database identity, which in turn corresponds to the state "transient" (and not detached), i.e. "new" w.r.t. persistence. Now suppose you pass that object to session.saveOrUpdate(); Hibernate sees the null id and says "oh, this is a new object, I need to give it a real ID and do an SQL INSERT". If, however, saveOrUpdate() were given a transient object with a non-null field, it would say "oh, this is a detached object, I have to re-attach it to the session".

If you use a non-nullable (primitive) type for the id, then you just have to remember to supply the 'unsaved-value' attribute in the mapping to specify what value (for instance, maybe 0 or -1) you want to mean "new".

I'm not aware of any other reasons (e.g. performace-related reasons as you suggest) for eschewing a ID types in favor of a class ("box") type, but I could be wrong.

Cheers,
—ml—