db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Extents and the various inheritance hierarchy mappings
Date Sun, 26 Oct 2003 16:40:13 GMT
hi brendan,

to make it clearer: the primary key has to be unique within the 
hierarchy defined in the repository (using extents).

i'll have a look at the mutants asap.


Brendan wrote:
> (Apologies all if this appears twice.)
> Jakob,
> 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.
> Brendan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

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

View raw message