Hi Tom,
Would that not require us to delay metadata processing of embeddable
class to deploy step? After all the cloned descriptor now have to be
populated with mapping information based on a different access type. Is
it worth the effort?
Is there a chance that we are not clear about the use case? Let me try
clearing this angle first. I have just now sent an email with the
modified rules. /They allow sharing of an embeddable in entities with
conflicting access-type provided the embeddable class has metadata in
it/. Sharing of *metadata-less* embeddable class is *not* allowed in
entities with *conflicting* access-types. Are you suggesting we support
this use case? I don't understand why we want to support this,
especially when we don't have all the necessary code in place. Setting
implementation challenge aside, I just think this use case should not be
allowed because it can lead to the same class being mapped *differently*
in different points of use. e.g. a typo can cause fields and properties
to be out of synch. Is that going to be more surprising to user?
Thanks,
Sahoo
Tom Ware wrote:
> Perhaps I am missing something. Can we store some information on the
> Embedded(Aggregate) mapping and use it to fix the AttributeAccessor on
> the cloned aggregate Descriptor at login time?
>
> -Tom
>
> Sanjeeb Kumar Sahoo wrote:
>
>> 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:
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>