>> 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

Reply via email to