hi chris, i added a fix to PB to handle abstract classes correctly. so imho multilevel hierarchies should work now. also changed hierarchy of the test class CdArticle by adding an abstract class above CdArticle. well, it's not as complicated as your class hierarchy but at least we have a testcase for multilevel hierarchies.
jakob ----- Original Message ----- From: "Chris Lewington" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Thursday, September 19, 2002 1:19 PM Subject: Re: Object Hierarchies Again > Hi Jakob, > > Well I checked out CVS head, and built an ojb 0.9.6 jar successfully - no > problems so far. First run against my test cases I got an error message from a > PB instance saying it could not find repository.xml. It was looking in my > execution directory, not the config directory where it is located. Seemed odd > as the *first* PB that loaded up read the repository.xml correctly from config, > but the second one that got created looked somewhere different for it! > > Anyway, hacked that by copying the repository to the excution directory as > well. Next problems were that a) no match came back (which was a failure) and > b) there were complaints from SQLExceptions about invalid columns for the > query. I'm guessing the SQL had been generated incorrectly for my test cases - > no problems before with our modified PB and ojb 0.9.2. > > Didn't have time to chase that one any further, I'm afraid. It looks like the > refactorings between 0.9.2 and 0.9.6 don't interact too well with our object > model setup for hierachies. As it works with 0.9.2 + our PB fixes I guess we'll > stick with that for now. > > Sorry I can't post the test cases as they are rather complex. However > (pre-empting your next question :-)) the basic setup is that we have abstract > classes (using lower case for abstracts, upper case for concrete) a-->b-->c. > The abstract class c then has two subclasses, one abstract and one concrete, > i.e. c-->d and C-->E. Then d itself has two concrete classes, ie d-->F and > d-->G. So E maps to table1 (say) and *both* F and G map to table2. The entries > in table1 and table2 are linked via an indirection table, table3. Now, a test > case to exercise all of this is to search for a (complete) instance of E. It > should check down the hierarchy when necessary, then search the concrete > classes F and G and materialise the appropriate object based on the correct > class descriptor and the entry in the indirertion table. As I said, what we > have now with 0.9.2 + PB fix seems to work in our setup for such queries. > > If you followed all of that, I am very impressed :-) Not sure if that helps you > if you want to track down the problem, but if I get any time spare I will try > and investigate further myself. > > Cheers, > > Chris > > > [EMAIL PROTECTED] wrote: > > > hi chris, > > > > well there have been a lot of changes in PB due to extent aware iterators. > > i itegrated your fixes into the newest PB and adapted it to support > > multilevel hierarchies. > > > > could you please test the current PB with your testcases ?? > > > > jakob > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
