What I meant by "Sharing of *metadata-less* embeddable in entities with
*conflicting* access-types" is the following:
@Embeddable public class C {
// has no metadata. It has two fields, but one property!
int i;
int j;
int getI() { return i;}
void setI(int i) { this.i = i;}
}
@Entity public class A {
@Id String id; // entity class uses FIELD access
@Embedded C c;
}
@Entity public class B {
String id;
C c;
@Id String getId() { return id} // entity class uses PROPERTY access
void setId(String id) { this.id = id;}
@Embedded C getC() { return c;}
void setC(C c) { this.c = c;}
}
My rules make this case illegal because:
If we allow this use case, then Class C will have two different
persistence views in the same PU. From A's point of view, it has two
persistence fields. From B's point of view, it has one persistence
property. I sincerely think, this kind of sharing should be disallowed.
User could have annotated either a field or property of C and that would
have not allowed sharing of the embeddable in A & B, but it would have
provided a unique view of C to both the enclosing entity classes.
Now you tell me, if you want to support this use case or not?
Thanks,
Sahoo
Tom Ware wrote:
> 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:
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>