currently there are problems when mixing extents and super-reference. imo it has something to do with Identity and caching.
the examples on the website do NOT mix those features. i always regarded multi-table join as a technical feature to support mapping ONE class onto MANY tables. in the repository those class-descriptors are connect using the super-reference. on the java-side inheritance is used and makes people think that they also need extents in the repository.
jakob
Gelhar, Wallace Joseph wrote:
Hi Jakob,
Sorry to be chiming in from left field, but does this imply that 'super' references and extents cannot be used together in the same object model? In the same class descriptor?
Please explain.
Wally
-----Original Message-----
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 6:53 AM
To: OJB Users List
Subject: Re: Wrong class materialized when selecting from an extent
mapped to a multi-table join
hi justis,
is this another case of mixing extents and 'super'-references ? i had a long offline discussion with brendan regarding this topic:
http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3933 http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3920
jakob
Justis Peters wrote:
Hi All!
Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible.
Upon converting some of the more complicated parts of my object model,
I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue,
so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead.
Anyhow, here is the summary of the bug. Any help would be appreciated:
====================================================================== ==== When selecting an entire extent from a parent class, the behavior
varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made:
Object model ------------ - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA
Test case 1
-----------
- start with a new JVM
- select all from extent InterfaceA.class, loop through and display the class for each
- select all from extent A.class, loop through and display the class
for each
- select all from extent B.class, loop through and display the class
for each
Test case 2
-----------
- restart with a new JVM
- select all from extent B.class, loop through and display the class for each
- select all from extent A.class, loop through and display the class
for each
- select all from extent InterfaceA.class, loop through and display
the class for each
Results
-------
- If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the
correct subclass and returns the expected instances with the appropriate queries.
- If using multi-table joins (see schema2.sql and
repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B".
For convenience in debugging, I have written a command-line test that
lets you choose the order in which the extents are retrieved and displayed. You can run it by doing:
java polymorphtest.PolymorphTest 0 1 2 (test case 1) OR java polymorphtest.PolymorphTest 2 1 0 (test case 2)
All the related classes, schemas, and O/R mappings are attached to this bug. Please contact me if you need help reproducing the errors.
================================================================
I don't want to send the attachments to the whole list, but I will be glad to email the tarball to whomever requests it. Thanks in advance for your help!
Sincerely, Justis Peters Oculan Corp. [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]
--------------------------------------------------------------------- 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]
