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 Sat, 22 Nov 2003 13:17:18 GMT
hi brendan,

sorry for the late answer. i was working on paging.
i'll forward this post to thomas, armin and oliver as well, because i 
think the issues discussed here need more attention.


Brendan Boesen wrote:

> 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'd like the have some kind of a real-world model that can be used for a 
tutorial application as well. something like the j2ee pet-shop ;) afaik 
this topic has been discussed some time ago.

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

i'd expect it.

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

- Identity(Class realClass, Class topLevel, Object[] pkValues) is used 
to build an identity using the keys only.
- the second seems quite clear, targetBroker is used to the pkValues 
(cld is taken from objectToIdentify.getClass()).
- the third allows more flexibilty, the cld is not taken using 
objectToIdentify.

getObjectByIdentity(Object pkValue, Class type) does not exist, but it's 
imo a simple combination of the first Identity-constructor and 
getObjectByIdentity(Identity id) .

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

??? could you please explain ???

jakob

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


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