>> In removing the separate mapping files for a subclass, it seems that I lost my ability to reference them directly. <<
huh? >> I am still fuzzy on the use of the <key/> in a joined subclass << >> On the other hand, this code doesn't pass muster with the runtime descriptor compilation because A and B cannot be directly referenced. << You are mistaken. >> It seems then that A and B could have both @hibernate.class and @hibernate.joined-subclass << No, you should never have this. >> For instance, if I change one of my subclasses, the superclass mapping does not get regenerated. It could be solved by having all of the mappings in a single file << yes, this is a problem. However, I think you'll find that even when using XDoclet, you still need to look at the actual .hbm.xml. If mappings for 50 classes or more were all generated into a single file, this would simply be hell. We should not change the XDoclet module (well, at least the default behaviour should stay as is ..... I suppose a switch could be added <hibernate ugly-monolithic-mapping-document="MyHugeFile.hbm.xml" version="2.0"/> would be ok :) The <key> element appears in various places, and is always used to define a Foreign Key that has no mapping to a Java property. In this case, it is the primary key of the joined-subclass table, which is also a foreign key pointing to the superclass table. |---------+-------------------------------------------> | | "Brian Topping" | | | <[EMAIL PROTECTED]> | | | Sent by: | | | [EMAIL PROTECTED]| | | ceforge.net | | | | | | | | | 07/08/03 06:44 PM | | | | |---------+-------------------------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: <[EMAIL PROTECTED]> | | cc: <[EMAIL PROTECTED]> | | Subject: RE: [Hibernate] questions about polymorphism | >------------------------------------------------------------------------------------------------------------------------------| > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Subject: Re: [Hibernate] questions about polymorphism > <snip stuff="good, thanks!"/> > >> Since the subclass is > completely described this way, is the separate mapping file for the > subclass > redundant? << > > You should not have a seperate mapping file for a subclass. I thought I was out of the weeds, but I guess not yet.... Another Q: In removing the separate mapping files for a subclass, it seems that I lost my ability to reference them directly. In reference to the contrived example below, I should like to be able to recover a reference to one object that contains a collection of the superclass objects. I would hypothetically iterate over the objects and decide what to do (although I don't generally use instanceof like this): /** * @hibernate.class */ public class Super { private Long id; /** * @hibernate.id column="id" unsaved-value="null" generator-class="native" */ public Long getId() { return id; } public void setId(Long id) { this.id = id; } } /** * @hibernate.joined-subclass * @hibernate.joined-subclass-key column="subKey" */ public class A extends Super { private B b; /** * @hibernate.many-to-one */ public B getB() { return this.b; } public void setTheContact(B b) { this.b = b; } } /** * @hibernate.joined-subclass * @hibernate.joined-subclass-key column="subKey" */ public class B extends Super { private java.util.Collection supers; /** * @hibernate.set role="Super" lazy="true" * @hibernate.collection-one-to-many class="Super" */ public java.util.Collection getSupers() { return this.supers; } public void setTheContact(java.util.Collection supers) { this.supers = supers; } } public static void main(String[] args) { // set up session // ... A a = (A) session.load(A.class, new Long(1)); B b = a.getB(); Collection bigBag = b.getSupers(); for (Iterator it = bigBag.iterator(); it.hasNext();) { Object o = it.next(); if (o instanceof A) { //... } else if (o instanceof B) { //... } } } So here are some questions/assertions i'd like to understand better: 1) I believe this code generates valid descriptors, but I am still fuzzy on the use of the <key/> in a joined subclass since I haven't made a full round-trip yet. I believe this is going to create a column in my superclass which is going to get filled by default with the fully-qualified class name of the subclass. In this case, using the same <key column="subKey"/> for each subclass is correct since a column named subKey will be created in table Super. (btw, this is what I was doing with EJB entities up until last week, with all kinds of crazed instantiator overrides built on home interface inheritance... it was just shy of unmanageable!) 2) On the other hand, this code doesn't pass muster with the runtime descriptor compilation because A and B cannot be directly referenced. It seems then that A and B could have both @hibernate.class and @hibernate.joined-subclass, but that would generate separate mapping files, going against your earlier negation of this. It's manageable with XDoclet since they don't need to be kept in sync, but maybe not ideal. The question is, will it work robustly in practice? 3) It seems that XDoclet could be expanded to better understand inheritance relationships when deciding what to generate. For instance, if I change one of my subclasses, the superclass mapping does not get regenerated. It could be solved by having all of the mappings in a single file, but there a reference in the manual saying that the best practice is to place each class mapping in its own file for team environments. Unless there is experience to the contrary, I'd like to change XDoclet to generate a single mapping file (or at least do so by a subtask switch). It makes sense because programatically determining inheritance in XDoclet is an n^2 operation, regenerating the entire file skips the step and is not a detriment in a team environment because developers don't check in the descriptor files anyway. thoughts/comments/input welcome and appreciated! -b ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel ********************************************************************** Any personal or sensitive information contained in this email and attachments must be handled in accordance with the Victorian Information Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 (Commonwealth), as applicable. This email, including all attachments, is confidential. If you are not the intended recipient, you must not disclose, distribute, copy or use the information contained in this email or attachments. Any confidentiality or privilege is not waived or lost because this email has been sent to you in error. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. ********************************************************************** ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel