Hi Jakob, Thanks for your reply! Yes. What you describe is exactly what I am doing.
I have read your discussion with Brendan, and I understand what you are saying. This is in direct conflict with what is implied in "http://db.apache.org/ojb/tutorial3.html";, though. The section titled "mapping classes on multiple joined tables" is located under the section "mapping inheritance hierarchies" and implies that you should be able to treat these items polymorphically. Particularly since it immediately follows the section that explains how to retrieve and handle polymorphic subclasses. In the current version (I am using RC4), I have just accepted that this isn't possible with a class hierarcy that spans multiple tables. My original database design had all the common elements in one table, and used additional tables to add on the information used by subclasses. Fortunately, I can change this (since I own the database). I will change to using a distinct table for each subclass, with all the fields repeated. Inside the database, I will simply create a new view that recreates what I had by having all the common data in one table. IMO, it would be a good feature to allow querying against an extent when your "extended" data is stored in separate tables. If it is not possible to include this, we could at least rewrite the tutorial to more clearly explain that if you select all elements from "org.apache.ojb.broker.A", you will not get any instances of "org.apache.ojb.broker.B", even if the data exists. Thanks again! Justis Peters Oculan Corp. [EMAIL PROTECTED] Jakob Braeuchi [EMAIL PROTECTED] wrote: > 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]
