Re: OJB not returning the correct child types.

Hi Gautam,

Virgo Smart wrote:
> Hello,
> 
> I tried out the problem again by making changes to the class-descriptors and schema 
> as per Armin's suggestions and the "Advanced O/R Mapping Technique" tutorial 
> (Apache OJB site). However the persistence broker still returns instances of Thing 
> class instead of the Book and Toy in the stuffInDrawer collection of the Drawer class.
>
> If there are any aspects that I might have over-looked, please point them out. Note 
> that Thing is a concrete class in my case.
>

You need OJB 1.0.4 or the latest version from OJB_1_0_RELEASE branch.

In OJB test-suite you can find a test called 
InheritanceMultipleTableTest#testInheritancedObjectsInCollectionReferences
which tests exactly your described scenario.
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/broker/InheritanceMultipleTableTest.java?view=markup

This test pass with all databases I use for testing (hsql, mysql, maxDB, 
OracleXE).


> I am thinking about modifying the OJB source code to fix this extent-awareness problem 
> satisfactorily. However I would need some guidance in helping me understand how OJB 
> creates SQLs in context of repository.xml (descriptors) and how RowReader and 
> RsIterator is used in creating instances of concrete classes.
> 
> Could any please help me understand the concepts related to SQL building, RowReader and 
> RsIterator and how the current implementation behaves ? Does anyone have a 
> sequence-diagram / activity diagram to illustrate the logic involved ?
> 
> I am thinking on the lines of using the class-descriptor to look out of extent-class 
> definitions for the class whose data in being read and in the process of being 
> materialized. If I find an extent-class, I would then look in to the table mapped to 
> this extent class for row-entry (using PK or PK/FK as the search criteria) and then 
> decide which object instance to materialize. 
> 
> I am not sure if this is the right way to go. Any advise or help on this is highly 
> appreciated.
>

I think there is no "extent-awareness problem" referring your 
Drawer-test. In InheritanceMultipleTableTest you can find many tests 
testing TPS-inheritance - only one specific scenario fail.

regards,
Armin

> Thank you for all the support.
> 
> Regards,
> Gautam.
> 
> 
> On Wed, 22 Nov 2006 Virgo Smart wrote :
>> Hello Armin,
>>
>> Apologies for posting a repeat of a similar problem as mentioned in an earlier post. I had already posted this one before I recieved the reply to the earlier one.
>>
>> Looking at the modified class descriptor, I see that the extent-class and anonymous fields are being dropped. I think this is ok. However I am not sure if the "super" reference descriptor can point to the primary key field descriptor of the parent class.
>>
>> Wouldn't this mean that the PK in the BOOKS / TOYS table would also need to be a FK pointing to the PK of the THINGS table ? Wouldn't this be illegal in SQL ?
>>
>> Thanks and Regards,
>> Gautam
>>
>>
>> On Wed, 22 Nov 2006 Armin Waibel wrote :
>>> Hi Gautam,
>>>
>>> as said in my previous post in thread "OJB: Identity equals method impl." you should use the "normal" TPS inheritance without a FK field and without "extent-class" declaration within TPS (and don't override fields in the sub-classes):
>>>
>>> <class-descriptor
>>>     class="Thing"
>>>     table="THINGS">
>>>
>>>     <field-descriptor
>>>         name="id"
>>>         column="ID"
>>>         jdbc-type="INTEGER"
>>>         primarykey="true"
>>>         autoincrement="true"
>>>         />
>>>
>>>     <field-descriptor
>>>         name="name"
>>>         column="NAME"
>>>         jdbc-type="VARCHAR"
>>>         size="255"
>>>         />
>>>
>>>     <field-descriptor
>>>         name="drawerId"
>>>         column="DRAWER_ID"
>>>         jdbc-type="INTEGER"
>>>         access="anonymous"
>>>         />
>>>
>>> </class-descriptor>
>>>
>>> <class-descriptor
>>>     class="Toy"
>>>     table="TOYS">
>>>
>>>     <field-descriptor
>>>         name="id"
>>>         column="ID"
>>>         jdbc-type="INTEGER"
>>>         primarykey="true"
>>>         autoincrement="false"
>>>         />
>>>
>>>     <field-descriptor
>>>         name="category"
>>>         column="CATEGORY"
>>>         jdbc-type="VARCHAR"
>>>         size="255"
>>>         />
>>>     </field-descriptor>
>>>
>>>     <reference-descriptor
>>>         name="super"
>>>         class-ref="Thing"
>>>     >
>>>         <foreignkey field-ref="id"/>
>>>     </reference-descriptor>
>>>
>>> </class-descriptor>
>>>
>>> <class-descriptor
>>>     class="Book"
>>>     table="BOOKS">
>>>
>>>     <field-descriptor
>>>         name="id"
>>>         column="ID"
>>>         jdbc-type="INTEGER"
>>>         primarykey="true"
>>>         autoincrement="false"
>>>         />
>>>
>>>     <field-descriptor
>>>         name="author"
>>>         column="AUTHOR"
>>>         jdbc-type="VARCHAR"
>>>         size="255"
>>>         />
>>>
>>>     <field-descriptor
>>>         name="isbnCode"
>>>         column="ISBN_CODE"
>>>         jdbc-type="VARCHAR"
>>>         size="255"
>>>         />
>>>
>>>     </field-descriptor>
>>>
>>>     <reference-descriptor
>>>         name="super"
>>>         class-ref="Thing"
>>>     >
>>>         <foreignkey field-ref="id"/>
>>>     </reference-descriptor>
>>>
>>> </class-descriptor>
>>>
>>>
>>> <class-descriptor
>>>     class="Drawer"
>>>     table="DRAWER">
>>>
>>>     <field-descriptor
>>>         name="id"
>>>         column="id"
>>>         jdbc-type="INTEGER"
>>>         primarykey="true"
>>>         autoincrement="true"
>>>         />
>>>
>>>     <collection-descriptor
>>>         name="stuffInDrawer"
>>>         element-class-ref="Thing"
>>>         >
>>>         <inverse-foreignkey field-ref="drawerId"/>
>>>     </collection-descriptor>
>>> </class-descriptor>
>>>
>>>
>>> The FK field "drawerId" in class Thing (of the 1:n reference in Drawer) is declared as anonymous. Please read carefully the section about how anonymous keys work to avoid problems
>>> http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do
>>>
>>> regards,
>>> Armin
>>>
>>> Virgo Smart wrote:
>>>> Hello,
>>>>
>>>> I am facing an issue when trying to retrieve the Drawer object.
>>>> Instead of retrieving a collection of Toy and Book instances in the stuffInDrawer attribute, collection containing Thing instances is returned.
>>>>
>>>> Following is the class descriptor that is used.
>>>>
>>>> <class-descriptor
>>>>     class="Thing"
>>>>     table="THINGS">
>>>>
>>>>    <extent-class class-ref="Toy"/>
>>>>    <extent-class class-ref="Book"/>
>>>>
>>>>     <field-descriptor
>>>>         name="id"
>>>>         column="ID"
>>>>         jdbc-type="INTEGER"
>>>>         primarykey="true"
>>>>         autoincrement="true"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="name"
>>>>         column="NAME"
>>>>         jdbc-type="VARCHAR"
>>>>         size="255"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="drawerId"
>>>>         column="DRAWER_ID"
>>>>         jdbc-type="INTEGER"
>>>>         access="anonymous"
>>>>         />
>>>>
>>>> </class-descriptor>
>>>>
>>>> <class-descriptor
>>>>     class="Toy"
>>>>     table="TOYS">
>>>>
>>>>     <field-descriptor
>>>>         name="id"
>>>>         column="ID"
>>>>         jdbc-type="INTEGER"
>>>>         primarykey="true"
>>>>         autoincrement="true"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="category"
>>>>         column="CATEGORY"
>>>>         jdbc-type="VARCHAR"
>>>>         size="255"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="parentThingId"
>>>>         column="THING_ID"
>>>>         jdbc-type="BIGINT"
>>>>         access="anonymous"
>>>>     >
>>>>     </field-descriptor>
>>>>
>>>>     <reference-descriptor
>>>>         name="super"
>>>>         class-ref="Thing"
>>>>     >
>>>>         <foreignkey field-ref="parentThingId"/>
>>>>     </reference-descriptor>
>>>>
>>>> </class-descriptor>
>>>>
>>>> <class-descriptor
>>>>     class="Book"
>>>>     table="BOOKS">
>>>>
>>>>     <field-descriptor
>>>>         name="id"
>>>>         column="ID"
>>>>         jdbc-type="INTEGER"
>>>>         primarykey="true"
>>>>         autoincrement="true"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="author"
>>>>         column="AUTHOR"
>>>>         jdbc-type="VARCHAR"
>>>>         size="255"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="isbnCode"
>>>>         column="ISBN_CODE"
>>>>         jdbc-type="VARCHAR"
>>>>         size="255"
>>>>         />
>>>>
>>>>     <field-descriptor
>>>>         name="parentThingId"
>>>>         column="THING_ID"
>>>>         jdbc-type="BIGINT"
>>>>         access="anonymous"
>>>>     >
>>>>     </field-descriptor>
>>>>
>>>>     <reference-descriptor
>>>>         name="super"
>>>>         class-ref="Thing"
>>>>     >
>>>>         <foreignkey field-ref="parentThingId"/>
>>>>     </reference-descriptor>
>>>>
>>>> </class-descriptor>
>>>>
>>>>
>>>> <class-descriptor
>>>>     class="Drawer"
>>>>     table="DRAWER">
>>>>
>>>>     <field-descriptor
>>>>         name="id"
>>>>         column="id"
>>>>         jdbc-type="INTEGER"
>>>>         primarykey="true"
>>>>         autoincrement="true"
>>>>         />
>>>>         <collection-descriptor
>>>>         name="stuffInDrawer"
>>>>         element-class-ref="Thing"
>>>>         >
>>>>         <inverse-foreignkey field-ref="drawerId"/>
>>>>     </collection-descriptor>
>>>> </class-descriptor>
>>>>
>>>>
>>>> I have used the table per subclass hierarchy strategy.
>>>> I have used SequenceManagerHighLowImpl as the sequence manager. The ids (ID column) in the TOYS and BOOKS tables are unique when the Drawer object is stored. In the sense, when a Drawer containing 3 things (2 books and 1 toy) is stored, the ids stored in THINGS table are 1, 2, and 3, where as the ids stored in BOOKS table are 1 and 2 and id stored in the TOYS table is 3.
>>>>
>>>> I hope I have provided sufficient details to debug the issue. Could anyone please point me as to where am I going wrong or if there is any way to circumvent the problem ?
>>>>  Thanks and Regards,
>>>> Gautam.
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
> 
> 
>  
>