I confessed that I didn't read his email, before I replied you. Sorry
about that.
There are a few types of polymorphism.
I would think that the outer join method is the extend approach.
The approach suggested by Richard Holmes is somehow
similar to what we calls "discriminator field" approach. Two approach
solve different set of problem. His approaches enable different class
to be used on the same set of persistence field. I don't have problem
with this approach, in fact I think we need both eventually.
However, I am a little bit doubt if it can be done safely in current
architecture. Object is instantiated and put in the transactional
object list, before the database fields are loaded. If we replaced the
instance after ClassMolder.load() is returned, it mean all other
objects loaded during the call may associated with the old instance
already, and we would create two instance of the same object. For
example, the classMolder.load() "product", might recursively load the
"product detail" that has a back reference. If we replace product with
another instance, then the "product detail" is holding a invalid
back-reference. It is true for more complicated object graph.
We aware the problem, and we are sure that we won't make the
same mistake in the new architecture.
Thomas
-----Original Message-----
>From: Thorsten Mauch [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 14, 2002 11:12 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Anybody currently working on Polymorhic Querys
/Collection
>
>Hi Thomas
>My idea is to follow the proposal from Ricard
>Holmes.
>
>http://castor.exolab.org/list-archive/msg11934.html
>
>of course this solutions is need a additional
>discrimiator field, but it works without object relloading
>and there is mo need for outer joins.
>Do you think this way passable ?
>
>-----Urspr�ngliche Nachricht-----
>Von: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Gesendet: Donnerstag, 14. Februar 2002 19:43
>An: [EMAIL PROTECTED]
>Betreff: Re: [castor-dev] Anybody currently working on Polymorhic Querys
>/Collection
>
>
>
>
>The 0.8.11 way of doing polymorphism is rather a dangerous.
>It does not always work. It depends on the order of the object being
loaded.
>Because of that, it shouldn't be put back.
>
>On the other hand, the right way to do it is done it in lower layer.
>Basically, having the SQLEngine to attempt to join the base and
>extend table. It also takes some research to see how such query
>can be generated. There is limitation on outer join on database...
>It also involves some major changes to include the new logic. It
>probably won't be fast and easy.
>
>
>
>Thomas
>
>-----Original Message-----
>>From: Thorsten Mauch [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, February 14, 2002 3:52 AM
>>To: [EMAIL PROTECTED]
>>Subject: [castor-dev] Anybody currently working on Polymorhic Querys
>/Collection
>>
>>Hi All
>>I Currently work to integrate Castor with Coocon and Chiba.
>>But due to the lack of polymorhism I can use the current castor
>>version.
>>I don't like to do this effort for Castor 0.8.11.
>>So for me is very important to bring back polymorhism back to castor.
>>Is somebody currently woorking on that ? The last info I have about that
>>is the post from Richard Holmes.
>>Anyway if somebody have haso ideas how to implement it fast in a easy way
>it
>>
>>would make me happy :)
>>For the moment performance is only on the second rank.
>>
>>THanx Thorsten
>>
>>-----------------------------------------------------------
>>If you wish to unsubscribe from this mailing, send mail to
>>[EMAIL PROTECTED] with a subject of:
>> unsubscribe castor-dev
>>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
