Yay! I've found the reason that the inheritence for userStatus didn't
work. Or at least, I've found the change I had to make to get it to
work. While the Address object was using a dynamic proxy, the UserStatus
was not. For some reason, giving UserStatus a dynamic proxy will make it
visible to any object that inherit from user.

This brings me to a (very minor) problem, the reason I removed dynamic
proxy from UserStatus, which was that I wanted to be able to use the
toString() method, which of course, when used on a dynamic proxy will
only return information about the proxy. 

Thanks,

Keith

>>> [EMAIL PROTECTED] 04/07/04 11:32AM >>>
Right, this is a bit embarrassing :-D - after complaining that
reference
descriptors are not inherited in multi-table inheritence, I'm now
going
to have to claim that they are. Sometimes.

My person class also has a reference to an address object. When I
retrieve a Student object (that inherits from Person), I can access
the
address perfectly. This is why I've been so puzzled by the problems
with
the User class.

This also works with lists. Person also has a list of qualifications,
that can be accessed from the Student object.

So the question is, why does the inheritence work between Student and
Person, but not between them and User?

Can someone confirm whether I should be using the extents tags as well
as the multi-table inheritence?

Here is the Student class-descriptor

<!-- STUDENT -->
<class-descriptor class="com.mp.hato.ojb.OJBStudent" table="students">
    <field-descriptor name="id" column="user_id" jdbc-type="INTEGER"
primarykey="true"/>
    <field-descriptor name="notes" column="notes"
jdbc-type="VARCHAR"/>
    
    <reference-descriptor name="super"
class-ref="com.mp.hato.ojb.OJBPerson" auto-retrieve="true"
auto-update="true" auto-delete="true">
        <foreignkey field-ref="id"/>
    </reference-descriptor>
</class-descriptor>

The address class-descriptor
<!-- ADDRESS -->
<class-descriptor class="com.mp.hato.ojb.OJBAddress" proxy="dynamic"
table="addresses">
    <field-descriptor name="id"         column="uid"       
jdbc-type="INTEGER" primarykey="true" autoincrement="true"/>    
    <field-descriptor name="line1"      column="LINE1"     
jdbc-type="VARCHAR"/>
    <field-descriptor name="line2"      column="LINE2"     
jdbc-type="VARCHAR"/>
    <field-descriptor name="town"       column="TOWN"      
jdbc-type="VARCHAR"/>
    <field-descriptor name="postcode"   column="POSTCODE"  
jdbc-type="VARCHAR"/>
</class-descriptor>

And the reference tag from the Person class-descriptor

<field-descriptor name="homeAddressId"             
column="homeAddress"                jdbc-type="INTEGER"/>
<reference-descriptor name="homeAddress"
class-ref="com.mp.hato.ojb.OJBAddress" auto-retrieve="true"
auto-update="true" auto-delete="true">
        <foreignkey field-ref="homeAddressId"/>
    </reference-descriptor>

The only difference that I could think of is that in the Person class,
if the address is null, the getHomeAddress method will create a blank
address - this isn't what I'm getting back though, I'm getting the
correct data from the database. However, implementing a similar check
for the getUserStatus method did not solve the problem. (I also tried
making the primary keys all autoincrement so they are the same, as Tom
suggested, but again, no joy)

Keith

>>> [EMAIL PROTECTED] 04/07/04 11:03AM >>>
Hi Tom,

Thomas Dudziak wrote:
> I wasn't aware that reference descriptors can be inherited !

The problem is that they can't ;-)
But to make the "Mapping Classes on Multiple Joined Tables" feature
full 
compatible we need inheritance of references in this case or the 
possibility to resolve the path to the reference.

> Is this
> somewhere in the docs ? I gotta check if this should be handled by
the
> XDoclet module ...

I will add a known issue note to release-notes, because I don't think
we 
will be able to fix this before final 1.0.

regards,
Armin

> 
> Keith, please ignore my post then ;-)
> 
> Tom
> 
> On Wed, 7 Apr 2004, Armin Waibel wrote:
> 
> 
>>Hi Keith,
>>
>>this is a known issue (sorry forget to answer your previous post). I

>>checked in a test called 
>>InheritanceMultipleTableTest#testQuery_InheritedReference a few days
ago.
>>I don't know a workaround for this problem. If you declare the
reference 
>>in the sub-class Person too you have to modify the sub-class table
and 
>>this will cause side-effects if you want all User with a specific
status.
>>The problem is that the path "userStatus.name" could not be resolved
by 
>>SqlGeneratorDefaultImpl.
>>
>>regards,
>>Armin
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] 
> For additional commands, e-mail: [EMAIL PROTECTED] 
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 



The information in this e-mail is confidential and intended to be
solely for the use of the addressee(s) and may contain copyright and/or
legally privileged information.  If you are not the addressee (or
responsible for delivery of the message to the addressee) please e-mail
us at [EMAIL PROTECTED] and delete the message from your
computer; copying, distribution, use or disclosure of its contents is
strictly prohibited.
As Internet communications are capable of data corruption no
responsibility is accepted for changes made to this message after it was
sent. For this reason it may be inappropriate to rely on advice
contained in any e-mail without obtaining written confirmation of it.
In addition, no liability or responsibility is accepted for viruses and
it is your responsibility to scan attachments (if any).
Please note that for business purposes, outgoing and incoming emails
from and to the company may be monitored and recorded.

Mouchel Parkman UK Ltd, Registered in England at West Hall, Parvis
Road, West Byfleet, Surrey UK KT14 6EZ Registered No : 1686040


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 



The information in this e-mail is confidential and intended to be solely for the use 
of the addressee(s) and may contain copyright and/or legally privileged information.  
If you are not the addressee (or responsible for delivery of the message to the 
addressee) please e-mail us at [EMAIL PROTECTED] and delete the message from your 
computer; copying, distribution, use or disclosure of its contents is strictly 
prohibited.
As Internet communications are capable of data corruption no responsibility is 
accepted for changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice contained in any e-mail without obtaining written 
confirmation of it.
In addition, no liability or responsibility is accepted for viruses and it is your 
responsibility to scan attachments (if any).
Please note that for business purposes, outgoing and incoming emails from and to the 
company may be monitored and recorded.

Mouchel Parkman UK Ltd, Registered in England at West Hall, Parvis Road, West Byfleet, 
Surrey UK KT14 6EZ Registered No : 1686040


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to