db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan Boesen <brendan.boe...@hesageek.com.au>
Subject Re: Extents and the various inheritance hierarchy mappings
Date Tue, 11 Nov 2003 12:21:06 GMT
Jakob,


> i'd prefer to use classes of the existing testcases if the provide all 
> the features we need to demonstrate the desired behaviour. or we can 
> use your testcases.
>

Originally I thought that that would be a sensible way to go.  I would 
have had to make some modifications to classes E, F, G, F1 and G1 so 
that I could test out Case 2 (0..n mappings).  On reflection, however, 
my opinion is that these classes are not complex enough to give OJB a 
real work-out in terms of all the test cases I would like to run.

Over the last few days I have set up the Entity-Role structure I talked 
about before and have performed simple tests against various object 
configurations.  Basically there are five tests and in each test I 
write and read the various objects:
   testShoolWithNoAssociations  (write/read school)
   testPersonWithNoAssociations  (write/read person)
   testSchoolAndTeacher  (write/read school, write/read teacher, 
write/read person)
   testSchoolAndStudent  (write/read school, write/read student, 
write/read person)
   testSchoolAndTeacherAndStudent  (write/read school, write/read 
teacher, write/read student, write/read person (for both teacher and 
student))

Here is what I found for the various mappings

1. Single table per concrete class
     No problems (Yippee!)

2. Shared table across subclasses
     Initially this failed but I found a bug, which I later discovered 
has since been fixed (by you I assume), in 
CollectionPrefetcher::associateBatched due to the possibility of a null 
'list' retrieved from the ownerIdsToList map.  So, now:
     No problems (Yippee!)

3. Separate tables (for superclass and subclass) with _separate_ pks 
per table
    Failed.  There appears to be a bug in 
ObjectReferenceDescriptor::getForeignKetFieldDescriptors which prevents 
a 1 to N mapping defined in superclasses from loading properly.  I have 
a possible fix which I'll forward separately.  Having made this fix, 
the first two cases pass but the later cases fail (write/read with 
school works fine but write/read with teacher or student ends up 
failing due to mutants).

4. Separate tables (for superclass and subclass) with _shared_ pk 
between subclass and superclass tables
Similar (or the same) problems as with 3.

Please note that these test cases are _extremely_ simple (create the 
model, save one of the objects, clear the cache, load the object by 
identity and do a compare of the original and re-loaded object graphs.) 
  I haven't even begun to try out query by class, etc (which I know will 
lead to problems in at least case 4 due to the extents issues).

Back to my previous comment on the test classes.  If these problems are 
only cropping up as complex mappings are being used, wouldn't it be 
better to define a more complex model for test cases which can tease 
out these issues?  Without having performed at least system-level tests 
against a reasonably complex model (and under various mapping 
strategies), I think it will be hard to be consider a 1.0 release of 
OJB as 'stable' (at least as far as supporting all the mappings it 
claims to support).

In order to improve this situation, I suggest the creation of another 
set of test cases which would operate at a higher level than the 
current suite of unit tests.  The purpose of these 'system' tests would 
be to show the high-level behaviour required by the OJB architecture as 
a whole.  I would expect that the same set of tests would be able to be 
run against various configurations, including various object-relational 
mappings.  (Another axis of variation would be the various client 
interfaces, ie: PersistenceBroker vs JDO, etc.)  Another advantage to 
creating tests against such a complex model is the potential to use the 
model and the various mappings for tutorial purposes.

What do people think?

>> I'll return to my example of the Entity-Role pattern as it also 
>> highlights some other issues.  I'll recouch your question in those 
>> terms: "We have a row in the ROLE table referencing entity 42.  How 
>> do we know whether it's a Person or a School?"  A similar question: 
>> "I have an entry in the role table with id 55.  How do I know whether 
>> that data belongs to a Role (if Role is not 'abstract' and is allowed 
>> to have instances), a Student or a Teacher?"
>
> in the case where one class is split into multiple tables the problem 
> stems from the strategy we use today. the two parts of the class (Role 
> + Teacher , Role + Student) are loaded individually. imo a joined load 
> of the subclass would avoid the problem.
>

Yes!  Would this strategy also allow the Role class to be made truly 
abstract?  (As you know, due to the load strategy, the Role class 
cannot be abstract because an instance of it is required to load in the 
Role-relate fields and then copy them to a Student/Teacher instance.)

>> Please forgive me if, in the following discussion, I go over ground 
>> that has already been covered in

[ Stuff deleted...]

>> 3. When you ask for an object by it's identity, there are a number of 
>> ways of doing it.  OJB currently supports three constructors for 
>> Identity:
>> Identity(Class realClass, Class topLevel, Object[] pkValues)
>> Identity(Object objectToIdentify, PersistenceBroker targetBroker)
>> Identity(Object objectToIdentify, PersistenceBroker targetBroker, 
>> ClassDescriptor cld)
>> I'm not quite sure I understand the utility of the last two.  Can 
>> someone demonstrate a real-world use for these two forms?  The first 
>> one is the totally flexible option but, unfortunately, requires 
>> someone to know the inheritance hierarchy of the classes and/or 
>> extents.  Shouldn't OJB support a simple getObjectByIdentity method:
>> broker.getObjectByIdentity(Object pkValue, Class type)
>> The second parameter is needed to identify not the _exact_ type of 
>> the class but the _starting point_ IN the _type hierarchy_ for the 
>> object you're trying to find.  Some examples:

Jakob, do you have any comments on this?  I am pretty confused by the 
three, imo, non-intuitive ways of doing object retrieval by identity.  
The proposed method getObjectByIdentity(Object pkValue, Class type) 
doesn't exist, does it?

>> 3.1 Subclasses and superclass in one shared table

[ Stuff deleted...]

>> There is _no_ Student with an id of 34
>
> ojb already supports this behaviour with the help of 
> 'ojbConcreteClass' and a column to hold the class-name.

Yeah, I've now had a chance to play with that mapping for the 
Entity-Role model.  After the latest changes to 
ObjectReferenceDescriptor it works great!

>> 3.2 Subclasses in separate 'concrete' tables (with included 
>> superclass data)

[ Stuff deleted...]

>> There is _no_ Student with an id of 34
>
> this also should be no problem and is already supported. but it relies 
> on the unique pk within the hierarchy !!
>

Again, I've since had a chance to try this out against the hierarchy 
and it certainly seems the most robust of the mapping techniques.  
However...

As I understand it, each time an object (or portions of an object) are 
written into a table, the unique pk for the table is generated from a 
HighLowSequenceManager specific to _that_ table.  Actually, it would be 
more accurate to say that the manager is associated with the Class 
corresponding to the _portion_ of the object's data being written (this 
last clairification is, of course, more important with cases 3.1 and 
3.2, where Role has one manager and Student and Teacher both have their 
own).  Correct?

In this case, the ids are not unique between manager instances.  When 
the various subclasses are mapped to their own separate tables what 
does that imply for the uniqueness of the pk _within_ (or _across_) the 
hierarchy?

>> 3.3 Separate tables for inheritance, _shared_ primary key between 
>> subclasses and superclasses:
>>

[ Stuff deleted...]

>> There is _no_ Student with an id of 34
>
> we currently do have problems with this scenario :(
> see my comment on mapping a class to multiple tables.
>

Funny, it was this one that started to lead me down this discussion in 
the first place!  :-)

>> 3.4 Separate tables for inheritance, separate key between subclasses 
>> and superclasses:

[ Stuff deleted...]

>> This is by far and away the most complicated case (and another reason 
>> I prefer the mapping in 3.3).
>
> but this one already works ;) although it's not really intuitive.
>

Well, unless I've got my mapping seriously screwed up, there are 
definitely problems with restoring a 1 to N mapping when it's defined 
in superclasses.  Plus there seems to be an issue with mutants being 
created (unless of course my temporary 'fix' to the first problem is 
causing this!).

[ Stuff deleted...]


Brendan


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


Mime
View raw message