AW: AW: [OJB-developers] Base class queries on inheritance mapped to 2 tables

[Mahler T. <tho...@it...>]

Hi Dale,

> -----Urspr=FCngliche Nachricht-----
> Von: Dal...@bd... [mailto:Dal...@bd...]
> Gesendet: Freitag, 15. Februar 2002 02:52
> An: Mahler Thomas
> Betreff: Re: AW: [OJB-developers] Base class queries on inheritance
> mapped to 2 tables
>=20
>=20
>=20
> Hi Thomas.
>=20
> I did some tracing through in the 0.7.343 code and finally=20
> got my two-table
> inheritance test working. I wasn't aware that in order for=20
> two-table inheritance
> to work, the query must be on an interface rather than a=20
> concrete class. Once I
> created [and queried on] an interface, the test was successful.
>=20
> Having to query on interfaces, however, might turn out to be=20
> rather limiting for
> programmers working with legacy code. If a programmer *must*=20
> use concrete base
> classes, OJB won't work for them because=20
> getCollectionByQuery() and other
> methods only check extents for interfaces.
>=20

Mmh, OJB provides support for queries against interfaces AND against
Baseclasses!
If you want to query against a base clase you MUST declare which =
derived
classes are in the baseclasses extent in the repository.xml.
There are several testcases that check this behaviour.=20

If some special things do not work we need testcases to demonstrate the
failure.

> BTW, this is also why single table inheritance doesn't work.=20
> In the example I
> posted with a base class and descendent class with different=20
> numbers of fields,
> the exception in the RsIterator was caused because the=20
> SqlGenerator was
> generating a query for the Base class (a concrete class with=20
> only 3 fields). It
> did this because the broker's collection and iterator query=20
> methods don't read
> extents for non-interface classes. There weren't enough=20
> columns in the ResultSet
> when it came time to materialize the Descendent class (a=20
> concrete class with 4
> fields, 3 from Base + 1).

I added this bug to my list. this must be fixed!

>=20
> I've been thinking that there might be two possible fixes for=20
> this. One fix
> would be to modify SqlGenerator.getListOfColumns to traverse=20
> extents. I think
> this would be more of a hack, though.=20

I agree!

>The second fix might be=20
> to rewrite the get
> collection/iterator functions to ignore the difference=20
> between interfaces and
> concrete classes and always traverse extents.

Yes this would match with my original extent concepts.

> Finally, to=20
> really make the code
> robust, Criteria (or Query) could be modified so that a user=20
> could specify a
> query for a base class and descendents, or just the base=20
> class. I don't know why
> someone would want to just query for base instances and not=20
> descendents, but you
> never know.

We already have this flexibility by modifying ClassDescriptors at =
runtime!

>=20
> I'll probably start trying out some of these changes myself.=20
> If you have any
> advice or input on this, I'd like to hear it.
>=20

IMHO the best thing is to preserve the original notion of extents. Thus =
I
prefer the second solution you mention!

regarding collaboration. I can add you to the OJB list of developers so =
that
you could check in your code directly into the cvs repository!=20
Please tell me your SourceForge account if you want to use CVS =
directly!

cu,

Thomas


> Dale Davis
>=20
>=20