-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 8 posts ] 
Author Message
 Post subject: Assigned Keys - pitfalls in using
PostPosted: Mon Aug 30, 2004 1:52 am 
Newbie

Joined: Mon Aug 30, 2004 1:37 am
Posts: 16
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 -
Quote:

5.1.4.5. Assigned Identifiers
Due to its inherent nature, entities that use this generator cannot be saved via the Session's saveOrUpdate() method. Instead you have to explicitly specify to Hibernate if the object should be saved or updated by calling either the save() or update() method of the Session.


In HIA in section 3.4.3 at the top of page 92 - regarding assigned identifiers:
Quote:
This strategy has some serious disadvantages when you're working with detached objects and transitive persistence..<snip/> Don't use assigned identifiers if you can avoid them.


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

In HIA in section 4.3.4
Quote:
Hibernate will assume that an instance is an unsaved transient if:
The identifier property (if it exists) is null.
The version property (if it exists) is null.
<snip.>


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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 30, 2004 3:38 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.

_________________
JAVA PERSISTENCE WITH HIBERNATE
http://jpwh.org
Get the book, training, and consulting for your Hibernate team.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Sep 07, 2004 6:12 pm 
Newbie

Joined: Mon Aug 30, 2004 1:37 am
Posts: 16
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":
Code:
<version name="version"
              column="VERSION"
              unsaved-value="0"/>

when I validated this against the dtd it failed due to the following definition:
Code:
<!ELEMENT version (meta*)>
  <!ATTLIST version name CDATA #REQUIRED>
  <!ATTLIST version access CDATA #IMPLIED>
  <!ATTLIST version column CDATA #IMPLIED>
  <!ATTLIST version type CDATA "integer">
  <!ATTLIST version unsaved-value (null|negative|undefined) "undefined">

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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Sep 29, 2004 6:26 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.

_________________
JAVA PERSISTENCE WITH HIBERNATE
http://jpwh.org
Get the book, training, and consulting for your Hibernate team.


Top
 Profile  
 
 Post subject: Confused
PostPosted: Wed Nov 08, 2006 6:35 am 
Newbie

Joined: Thu Oct 19, 2006 10:39 pm
Posts: 9
Location: London
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


Top
 Profile  
 
 Post subject: Hibernate3 allows saveOrUpdate semantic with assigned keys
PostPosted: Wed Nov 08, 2006 7:11 am 
Newbie

Joined: Thu Oct 19, 2006 10:39 pm
Posts: 9
Location: London
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 08, 2006 7:49 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
http://www.manning.com/bauer2


Top
 Profile  
 
 Post subject: Re: Confused
PostPosted: Fri Dec 29, 2006 2:56 am 
Newbie

Joined: Mon Jun 12, 2006 2:39 am
Posts: 1
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


jdb197 wrote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 8 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.