Hi Gautam,

Virgo Smart wrote:
Hi Armin,

I was able to locate the code in the OJB source.

If you run the OJB test suite

http://db.apache.org/ojb/docu/testing/testsuite.html

all generated sql-scripts can be found in
[db-ojb]/target


However there are a few things that I cannot understand.
Why do we have composite primary keys for the Employee, Executive and Manager entities ?

Cause it's a test case ;-)
It's not mandatory to use composite PK. Often I use the most "complicated scenario" when I wrote a test case to cover most scenarios.

regards,
Armin


Thanks and Regards,
Gautam.

On Tue, 28 Nov 2006 Virgo Smart wrote :
Hi Armin,

Thank you for point me to the test case method. I had a look through the 
testInheritancedObjectsInCollectionReferences method and it seems to me that it 
replicates the scenario I have been facing issues with.

Could you please send me the repository.xml descriptor, the Torque schema (if 
available) and the Java source files to enable me to simulate the scenario at 
my end ?

Thanks a lot for all your help and support.

Regards,
Gautam.

On Tue, 28 Nov 2006 Armin Waibel wrote :
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]




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

Reply via email to