db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan <bboe...@tpg.com.au>
Subject Re: Extents and the various inheritance hierarchy mappings
Date Fri, 24 Oct 2003 14:41:02 GMT
(Apologies all if this appears twice.)


Thanks for fixing the duplicates problem!

> the other problem (wrong class instantiated) is caused by duplicate 
> primary keys within a hierarchy. ojb requires the pk to be _unique_ 
> within the hierachy. otherwise getObjectByIdentity could return 
> multiple objects.

I'm not quite sure I understand the implications of what you are saying 
(though I do understand the statement itself).

Classes E, F and G all have their own unique primary keys.  A query 
against E and F returns mutants.  How do you do a query against class E 
and not get bogus results?

Classes E, F1 and G1 use a shared primary key.  Is this a contradiction 
of your statement above?  (I've checked that getObjectByIdentity does 
not return multiple objects in this case BTW.)

Slight digression:
In my opinion the E, F1 and G1 table mapping is a valid and quite 
useful table mapping (especially for someone looking at this data in a 
relational way through something like sqlplus).  Talking about classes 
E, F1 and G1 leads on to the other issue that we have already 
discussed, which is the fact that you cannot use extent with these 
classes.  I still consider this a limitation of OJB.  Does anyone else 
have any comments?

I've had a chance to look at the extent query code and (think) I have a 
pretty good idea about why the mutant problem is occurring.  The way 
that the queries are done is top down, starting with the query class 
and then working down through its extents.  Queries are executed 
against each class in the extent tree and then chained together 
(ChainingIterator containing an RsIterator for each extent class and 
one for the root class).

An alternative way to doing this is to query bottom up and add the 
results to a set (not a java Set but some collection that implements 
set semantics based on a unique id).  However, this would require a 
pretty significant change to the use of Iterators.  (Is there some 
reason why the Iterator style is superior to passing in a 'set' and 
adding the results to it?  Both seem a valid and logical way of doing 
it from a design point of view.)  The queries against the superclasses 
(when going bottom up) are still useful for two reasons: i) Subclasses 
instances need data from their superclass tables - it would be good if 
this data could be used when the superclass relationship is resolved, 
rather than having to get it all over again ii) Certain superclass 
tables entries will be instances in their own right and not just an 
artifact of the inheritance hierarchy to table mapping.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message