[ http://thecla.homeftp.net:8380/jira/browse/HIB-59?page=comments#action_11120 ] David Allen commented on HIB-59: --------------------------------
The preliminary fix is good since the semantics are otherwise difficult. The point that the business key fields cannot change is a good one. This is something that would have to be carefully managed by the application. Most examples where the business key makes more sense are the following based on a multi-user web app creating entity instances: 1. Some action results in a couple of entities being created. In order to guarantee that none of them are duplicates in terms of business rules, only business keys can be used. (Note that no primary key has been generated yet since they are not yet in the store.) 2. Some action wishes to add a new entity to a collection in another entity. Again to make sure it is not a duplicate, the primary key cannot be used since it is not generated. Besides, Hibernate will always generate new keys for any object with a null one. In (2), which is more common, the "small" collection in another entity is only a subset of a larger collection of all instances. The foreign key constraints identify that subset, while each has a unique identifier in the context of the larger collection (the primary key). In the "small" collection, another attribute may need to be unique as the display name for that object in the webapp. In other words, a business key is really being used locally, even though it is not necessarily unique across all instances of that entity. It is only unique within the "small" collection. In UML, this is closely related to association qualifiers, where any subset of fields may be used to retrieve an instance from a collection. The qualifier is not global across all instances, just those which happen to be in that association for a given parent entity instance. I do not mind overriding the equals()/hashCode() methods where this makes sense, as I did in a prior release. If no business methods exist, however, the *Impl class is not generated or mapped. So currently I am stuck with no longer being able to override the behavior, even though the default is now to use the primary key as the object identifier. I guess I can just define equals() in the UML models on entities where this is needed. > 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.html#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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://thecla.homeftp.net:8380/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- 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
