Do you mean that the entity identifier attribute is used for identity? As described in the Hibernate documentation, that will not work when a non-persisted entity is compared with an existing persisted entity (unless you happen to have the auto-generated key). Of course, the only solution with business "keys" would involve some sort of modeling change with the UML.
On Wednesday 09 March 2005 03:17 pm, Wouter Zoons (JIRA) wrote: > [ > http://thecla.homeftp.net:8380/jira/browse/HIB-59?page=comments#action_1110 >8 ] > > Wouter Zoons commented on HIB-59: > --------------------------------- > > for now I implemented a preliminary fix: each entity checks the identifiers > modeled onto itself, if the entity extends another entity it will also use > the equals() and hashCode() methods of that one in the process > > using business properties only makes sense when they are never updated > during the lifetime of the instance (see the hashCode contract here: > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#hashCode()) > > more comments welcome, add one when you have a concrete idea for > implementation > > > Java object identity > > -------------------- > > > > Key: HIB-59 > > URL: http://thecla.homeftp.net:8380/jira/browse/HIB-59 > > Project: Hibernate Cartridge > > Type: Improvement > > Versions: 3.0RC1 > > Reporter: David Allen > > Assignee: Martin West > > Priority: Minor > > > > > > > > Since some of the implementation classes are now placed under the > > target/src directory, it would be nice to automatically produce the > > equals()/hashCode() methods to handle object identity in Java. For a > > good, concise description, see section 4.3 of the Hibernate Reference > > docs at > > http://www.hibernate.org/hib_docs/reference/en/html/persistent-classes.ht > >ml#persistent-classes-equalshashcode. Depending on the model and how an > > entity is used, there will be cases where some subset of attributes, > > including a subset of 1, may be used to uniquely identify the object > > between Hibernate sessions in collections. For reasons described in the > > Hibernate reference above, this often cannot be the primary key > > (auto-generated) of the entity, but must be some business key that is at > > least relevant within the context that the entity will be used. > > Generating the methods in the *Impl classes can be fairly > > straightforward. The only design decision to make here is how to let the > > modeller define which subset of attributes on an entity define a business > > key. Possibilities include: 1. A new stereotype, like <<primaryKey>>, > > but for business key attributes, 2. A tagged value to add to such > > attributes (similar to ones for "indexed", "unique") This only affects > > the *Impl classes, or perhaps it should really be in the main class, > > since the Hibernate engine does not need it. Within a single Hibernate > > session, the cache takes care of these issues. Only outside of a > > session, or between sessions, does the object identity become an issue. -- David Allen [EMAIL PROTECTED] ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
