Hi Matt,
I agree that the current implementation is not optimal.
Your proposal 3 sounds good to me.
But I believe that it needs an intense redesign of parts of the query
mechanism.
This will be a lot of work... I don't know if I can implement your
request soon.
Maybe someone is volunteering on this problem ?!
regards,
Thomas
Matt Goodall wrote:
> Hi all,
>
>
>
> I've got a few more comments on the "inheritance mapping on one table"
> scenario ...
>
>
>
> 1. Extra objects are created
>
>
>
> When retrieving all records of a derived class creates an object for
> *every* record in the table regardless of whether the ojbConcreteClass
> matches the type (or derived type) requested. Obviously, that has a huge
> performance impact if the table is large.
>
>
>
> I tried implementing a RowReader and returning a null class descriptor
> when I didn't want to load the record but that just makes it think that
> they were of the type I requested so I got extra matches.
>
>
>
> 2. You have to map all objects stored in the table
>
>
>
> At the moment, I don't care about a lot of the data in the table I'm
> using but OJB insists on loading everything and then starts failing when
> it finds a type I haven't mapped in the repository yet. It would be
> really nice if these objects could be silently ignored.
>
>
>
> 3. The SQL query could be improved
>
>
>
> If you load all objects of a derived type then OJB actually retrieves
> every record in the table. It seems to me that since the repository
> knows the inheritance graph for all these classes it could construct a
> where clause to reduce the number of records loaded.
>
>
>
> Just in case that's not clear, here's a contrived example. Given a class
> hirearchy of
>
>
>
> Fruit
>
> Orange
>
> SevilleOrange
>
> Satsuma (yeah, I know it's not an orange - I said it was
> contrived)
>
> Banana
>
>
>
> When you ask for all Orange objects the where clause could be "where
> ojbConcreteClass in ('Orange', 'SevilleOrange', 'Satsuma')".
>
>
>
> In fact when you ask for all Fruit objects it could build a where clause
> for all types in the hierarchy and any unmapped types would not be
> retrieved.
>
>
>
>
>
> It looks like the implementation of 3 would actually solve 1 and 2.
>
>
>
> Thomas, can you see any problems with this - I have very limited
> knowledge of OJB's implementation at the moment.
>
>
>
> Cheers, Matt
>
>
>
> ---
>
> Matt Goodall
>
> Analyst Programmer, Strategic Systems Solutions
>
> e: mat...@ss... <mailto:mat...@ss...>, t: +44
> 113 3892645
>
>
>
|
