So, I read on the website that you can not, and should not, change the primary key and that hibernate will not allow you to do that. Is this right?

Lets say I want to update the value of the PK of a building, say its name. If the building name is the PK I can't change the name, even if the name I am changing it to is still unique??

That would suck if you can't, I know on the DB sides of things you can.

brandon

The recommendation is to use a surrogate key (i.e. BuildingId) with no business meaning as a primary key. This makes sense for a number of reasons. The business key, Name, should be a separate column with its own semantics (unique constraint, not-null, etc.). You would use this key to implement hashcode( ) and equals( ) to create the appropriate behavior in Sets.

For legacy systems it is possible to specify a business key as a primary key, but you run into several problems. First, an ORM tool has no way of knowing what the old key is, so updates are impossible. If you changed the name from "Bldg 305" to "Blg 306" then Hibernate can't say "Update building set name='306' where name='305'" because the 305 is lost. Because it's the primary key, the only way to retain it would be to save a copy somewhere, necessitating a tighter coupling, etc. You could, I suppose, update the name where all of the other fields are the same, but there's nothing to say the other fields couldn't have changed as well. There's no simple, efficient, or reliable way to change a primary key.

The other problem is associations and inverse relationships. I haven't thought through the gamut of complications that a changeable primary key would cause with those, but I imagine it's quite a mess.

What you could do, I suppose, is delete( ) the object, change the key, and then save( ) the object, which might, depending on your associations and cascade settings, re-persist your entire object graph in the database. It's also kind of risky, since you are in essence deleting things and re-inserting them.

- Jesse

Thank you for the explaination about how Hibernate takes care of Primary keys and how it is not recommended to delete the PK.

I understand where you are coming from, howeve I am use to having control of the database on the application (2-tier), not having a presistance layer (hibernate).

When I usually do this (change PK) all I have to do is set up my FK constraints and what their referintial intergrity rules are. If I change a PK in building table and have these rules/constraints set up properly, the changes will propagate to all the tables that need to be updated. thus, making it easy and flexible to change the PK. This will rule out the need to have a surrogate key, since the whole point of having a database is to:

Correspondence Theory
model the world and then ask questions about the DB to get answers rather than having to go out into the real world and find them.

By having a surrogated key that has nothing to do with the data that is being captured, it takes away from the "relational" aspect of the database. Having said that, surrogated keys are always used in the "application" world and not the "ideal" world.

thanks for you info. I not sure what to do...