It occurred to me after reading your post that you wouldn't need to compare id because the primary key isn't going to change once the row has been inserted in the database and you only need to deal with this concurrency issue on updates and deletes. I think you would need to check all the other fields though. However, I now have another issue that I am not sure how to deal with. Suppose you have an object of Foo which contains a list of Bar objects and Bar did not point back to the Foo instance which contained it. In the database, this relationship would be expressed as a foreign key in the BAR table which would not be represented by a field in the Bar object. If user 1 chooses to update a Bar instance while user 2 is removing that instance of Bar from some instance of Foo and user 2 commits changes before user 1, user 1 won't know that the object has changed while the Bar instance was detached. Is there a Best Practice for dealing with this case?
Thanks for your help, Rob -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 05, 2006 4:38 PM To: Tapestry users Subject: Re: OT: equals method for persistent objects Have one really simple part of your equals method that compares db id's, and if one of them isn't set, alternatively compare whatever else is available. (not ~everything~, just enough to give you uniqueness, if that's possible :) ) On 4/5/06, Rob Dennett <[EMAIL PROTECTED]> wrote: > > The Hibernate documentation recommends implementing equals and hashCode > using an objects business key rather than the database id. Kent Tong in his > excellent book _Enjoying Web Development with Tapestry_ implements equals > using all fields of his example object, including the field which contains > the database id and fields which are not part of the business key, in order > to deal with concurrency issues. The issue with using the database id as > part of the equals method is that it prevents you from adding an unpersisted > object to a set. The problem with using fields that are not part of the > business key is that if the object points to a large graph, the compare can > be deep and expensive in terms of processing time. The problem with not > using the id field and non-business key fields is that you can't compare a > database instance with its cached copy to see if it has changed before > committing changes. So what should you do here? > > > > Thanks for your help, > > Rob > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 > > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
