Hibernate version:
2.1.6
Name and version of the database you are using:
PostgreSQL 7.4.3

First off - Thanks for a great book. I had worked through another smaller book on Hibernate which was very good for getting up and running quickly, but almost led me to rejecting Hibernate for my application when I saw the sql the examples generated. I'm so glad HIA became available - it's been a real eye opener to the power of Hibernate.

Now to my question. I am trying to understand any drawbacks of using "assigned" identifiers - and want to be sure that I am not missing something.

This note in the Hibernate Reference document worried me at first -


In HIA in section 3.4.3 at the top of page 92 - regarding assigned identifiers:


OK, now I'm even more worried about using them.

In HIA in section 4.3.4


Aha, that sounds better!

Again in HIA in section 8.3.1 there is a discussion on mapping a table with a natural key. This indicates that by using a version property in classes with assigned keys, that saveOrUpdate() and cascades will work correctly.

So, if I make sure that all my classes which will use assigned identifiers also have a version property, does that resolve all issues in using them as detached objects and using transitive persistence? Are there any other downsides/limitations/catches to using assigned ids in Hibernate?

Thanks,
Grainne.

We like to scare people about this, since it is usually a) a design that will bite you later and b) should only be used for legacy systems. Yes, if you have a version property, all is fine. But again, if you start from top-down with a new application and database, use surrogate keys.

Thanks for your response - it helps a lot to have this confirmed.
I thought I should point out an inconsistency between the example of using an unsaved-value with version in section 8.3.1 of HIA and the hibernate-mapping-2.0.dtd definition.
In the example the unsaved-value is set to "0":

when I validated this against the dtd it failed due to the following definition:

I'm hoping that the dtd is being overly restrictive and that you can in fact use "0"as the unsaved value as per the example.

Grainne.

This is a serious error in the book (that part of the code hasn't been tested, unfortunately...). The mapping should be "unsaved-value=negative" and the declaration of the version property in the class "private int version = -1".

This will be fixed in reprint and mentioned in the errata.

I agree that many different people talk about the problem of using assigned identifiers, as discussed above.

The question I have is that I have implemented a solution (as you are not supposed to) using assigned identifiers, with no version or timestamp field.
I find that saveOrUpdate appears to work correctly. I also find it cascades correctly through several layer of objects.

When I create a new object graph the entire graph is saved correctly. When I update non-key values the relevant rows are updated correctly. Surely this encapsulates the key functionality of saveOrUpdate?

Given that I am restricted by a legacy schema used by many other applications (that I cannot change) and what I am doing works, why is the approach I have taken considered such a bad idea?

Is there something I am missing?

Thanks,

James

Apparently Hibernate3 now allows saveOrUpdate semantic with assigned and composite keys does anyone have more info on this as I can't seem to find it in the current Hibernate documentation.

Cheers,

James

Have you tried updating (part of the) key values?

Like when, you have a composite natural key (assigned), e.g. a link table with 2 fields to simulate a n-n relationship, and you want to change an existing relationship to be linked to somthing else now?

e.g.
tblPersonPhone(idPerson, idPhone)
contains a value
(1, 3)
and you change it to (1, 4)
and then call saveOrUpdate