Tom,
AggregateObjectMapping.initialize(AbstractSession session) which does
the cloning is called during deploy() step. MetadataProcessor is called
during predeploy() step. While processing the entities,
MetadataProcessor also processes the referenced embeddable class if that
embeddable is not yet processed. So, MetadataProcessor has access to
only one ClassDescriptor for an embeddable class. Cloning happens later
on during deploy(). So, I don't understand how we can support
conflicting views of an embeddable class?
Thanks,
Sahoo
Tom Ware wrote:
> Hi Sahoo,
>
> Aggregate descriptors are cloned at session initialization time.
> AggregateObjectMapping.initialize(AbstractSession session) does the
> cloning. As each AggregateObjectMapping initializes itself, it takes
> a copy of the Aggregate descriptor that was created prior to
> initialization and makes changes to it so that it is appropriate to
> the object it is actually mapped on. Currently, some of the changes
> include setting the tables and primary key fields to be the correct
> ones for the table the object that encloses it uses.
>
> -Tom
>
> Sanjeeb Kumar Sahoo wrote:
>
>> Tom,
>>
>> As far as I know TopLink Essential maintains one *ClassDescriptor*
>> per *JavaClass* in the Project object (there is Map<Class,
>> ClassDescriptor> in Project). This is why I suggest we throw an
>> exception if an embeddable that has no metadata in it is used in
>> entities with conflicting access-types.
>> I don't understand why Marina mantioned that TopLink creates a copy
>> of the model for each use of the embeddable class and you also agreed
>> with her. Can you please clarify this?
>>
>> Thanks,
>> Sahoo
>>
>> Tom Ware wrote:
>>
>>
>>> That corresponds with my understanding.
>>>
>>> -Tom
>>>
>>> Marina Vatkina wrote:
>>>
>>>
>>>> Sahoo, Team,
>>>>
>>>> We discussed with Tom the short term requirements to fix this
>>>> issue, and
>>>> agreed that for now we should not change the behavior supported by the
>>>> current code. Tom, please correct me if I miss anything.
>>>>
>>>> TopLink is able to support sharing an Embeddable between 2 entities
>>>> with
>>>> different access type, because it creates a copy of the model for each
>>>> owner. Which means that the best current approach to fix this bug
>>>> (we can
>>>> continue philosophical discussions about the features) should be:
>>>>
>>
>>
>>
>