Re: [OJB-developers] "inheritance mapping on one table" performance

[Thomas M. <tho...@ho...>]

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
> 
>  
>