From: <leg...@at...> - 2003-09-12 03:27:27
|
The following issue has been updated: Updater: Gavin King (mailto:ga...@in...) Date: Thu, 11 Sep 2003 10:26 PM Comment: This is not really a _bug_... I agree that the current design, where CollectionPersister is a single class, rather than an interface, could be vastly improved. Changes: type changed from Bug --------------------------------------------------------------------- For a full history of the issue, see: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-326&page=history --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-326 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-326 Summary: Persister assigned to a class not used when persisting a Set Type: Improvement Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0 final Assignee: Reporter: Nick Johnson Created: Thu, 11 Sep 2003 4:56 PM Updated: Thu, 11 Sep 2003 10:26 PM Environment: JDK 1.4 on Win2k Description: When persisting a Set, the persister for the class defined within the Set is not used. For example, with a mapping like this: <class name="foo" persister="FooPersister"> <!-- ... --> <set name="relatedStuff"> <key column="related_stuff_key" /> <one-to-many class="bar" /> </set> </class> <class name="bar" persister="BarPersister"> <!-- ... --> </class> Operations on the set "relatedStuff" will result in SQL being generated rather than the necessary operations being handed off to BarPersister. Another alternative or possible solution to this problem would be the ability to define a custom persister for Hibernate's collections classes; eg, "<set name="relatedStuff" persister="CustomSetPersister">" This problem arose because we need to control how a many-to-many-style table is persisted (we use stored procedures to do inserts, updates and deletes). Because of the way the tables are normalized and because of the requirements of the system (arbitrary linkage between collections and the necessity of interoperating with existing infrastructure) the schema looks something like this: Group ----- group_id number primary key (other attributes on group follow) Group_member ------------ parent_group_id number (references the group_id in Group) child_group_id number (ditto) The original problem is that we've been unsuccessful in getting customized persistence for the Group_member table. Even creating a custom persister for the Group_member table still results in SQL getting generated rather than the custom persister being used. This turns out to be a difficult thing to describe, so if what I've said isn't terribly clear, I'm more than happy to try to clarify ambiguities. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |