Hi Sahoo,
I am a little unclear on what "Sharing of *metadata-less* embeddable
class is *not* allowed in entities with *conflicting* access-types"
means, but I think we can leave that since Mike is going to send an
answer that should cover the rules you suggest.
I believe the technical question relates to whether updating the
descriptor after it is cloned results in processing of part of the
information about the embeddable class at the deploy step and whether it
is worth the effor. I guess the question of whether it is worth the
effort comes down to whether we can support the usecases we want to
support without doing it.
As I mentioned above, I'm going to try to avoid duplicating Mike's
response to avoid confusion, so perhaps when you have seen what he has
written, you can tell me whether or not we need to do that extra processing.
-Tom
Sanjeeb Kumar Sahoo wrote:
>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:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com