Yes, I understand it is temporary, and greatly appreciate it as it does fix the more serious problems of entity collections.
I have been trying to think of a good solution to this in general, but have not really come up with anything yet. I hate adding more stereotypes or tagged values. Maybe association qualifiers are the answer, but they too have some strange cases. On Friday 11 March 2005 04:36 pm, Chad Brandon (JIRA) wrote: > [ > http://thecla.homeftp.net:8380/jira/browse/HIB-59?page=comments#action_1112 >2 ] > > Chad Brandon commented on HIB-59: > --------------------------------- > > We aren't saying this is the end all solution to this problem, just a > temporary fix, I was just curious why you'd need to know about unique > business keys outside of the context of a persistent entity (before they're > persisted I mean)...and you brought up some good examples of why, so I > still think we should address this in a better way. > > > Java object identity > > -------------------- > > > > Key: HIB-59 > > URL: http://thecla.homeftp.net:8380/jira/browse/HIB-59 > > Project: Hibernate Cartridge > > Type: Improvement > > Versions: 3.0M3 > > Reporter: David Allen > > Assignee: Martin West > > Priority: Minor > > Fix For: 3.0RC1 > > > > > > > > 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
