Home » Modeling » EMF » [CDO] My EStructuralFeatures lose their eTypes
| [CDO] My EStructuralFeatures lose their eTypes [message #909725] |
Fri, 07 September 2012 16:41  |
|
Hi,
I have a CDO repository with the supportingEcore property set to true,
so that I can store UML and Ecore models in legacy mode.
When I commit an EPackage (in a CDOResource) to the repository, all of
the EStructuralFeatures of its EClasses lose their eType references.
When I load the resource again in a new transaction, my EAttributes
have no types. For example, an attribute that looks like this in XMI:
<eStructuralFeatures xmi:type="ecore:EAttribute"
xmi:id="_99Kc9vh2EeG_Su_GArlGLw" name="permanent" ordered="false"
lowerBound="1">
<eType xmi:type="ecore:EDataType"
href="http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
</eStructuralFeatures>
(using the URI of the registered Ecore package to reference the
EBoolean type) ends up with null type in the repository.
I thought that supportingEcore should let me store Ecore models in
legacy mode, and that references to statically-registered EPackages
would be resolved by the resource set as usual in both the server and
the client.
Am I doing something wrong? Missing something?
Thanks,
Christian
|
|
|
| Re: [CDO] My EStructuralFeatures lose their eTypes [message #909779 is a reply to message #909725] |
Fri, 07 September 2012 19:20  |
|
Actually, I'm finding that even eType references *within* a single
Ecore resource in the repository are lost.
The problem isn't restricted to references to types in registered packages.
Now I really think I'm doing something wrong. But, my repo has
"supportingEcore" enabled and the Ecore EPackage registered and legacy
mode turned on. What else could I need?
cW
On 2012-09-07 16:41:47 +0000, Christian W. Damus said:
> Hi,
>
> I have a CDO repository with the supportingEcore property set to true,
> so that I can store UML and Ecore models in legacy mode.
>
> When I commit an EPackage (in a CDOResource) to the repository, all of
> the EStructuralFeatures of its EClasses lose their eType references.
> When I load the resource again in a new transaction, my EAttributes
> have no types. For example, an attribute that looks like this in XMI:
>
> <eStructuralFeatures xmi:type="ecore:EAttribute"
> xmi:id="_99Kc9vh2EeG_Su_GArlGLw" name="permanent" ordered="false"
> lowerBound="1">
> <eType xmi:type="ecore:EDataType"
> href="http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
> </eStructuralFeatures>
>
> (using the URI of the registered Ecore package to reference the
> EBoolean type) ends up with null type in the repository.
>
> I thought that supportingEcore should let me store Ecore models in
> legacy mode, and that references to statically-registered EPackages
> would be resolved by the resource set as usual in both the server and
> the client.
>
> Am I doing something wrong? Missing something?
>
> Thanks,
>
> Christian
|
|
|
| Re: [CDO] My EStructuralFeatures lose their eTypes [message #909784 is a reply to message #909779] |
Fri, 07 September 2012 19:32 |
|
Hmmm . . .
The ETypedElement eType reference and eGenericType containment
reference are derived from one another. Both are marked as volatile
but neither is marked as derived in Ecore.ecore. However, the problem
that I'm seeing is that the EGenericType that references an
ETypedElement's type is not stored in the repository, or at least it
isn't loaded back from the repo.
Could CDO be ignoring volatile containment references somewhere?
cW
On 2012-09-07 19:20:37 +0000, Christian W. Damus said:
> Actually, I'm finding that even eType references *within* a single
> Ecore resource in the repository are lost.
>
> The problem isn't restricted to references to types in registered packages.
>
> Now I really think I'm doing something wrong. But, my repo has
> "supportingEcore" enabled and the Ecore EPackage registered and legacy
> mode turned on. What else could I need?
>
> cW
>
>
> On 2012-09-07 16:41:47 +0000, Christian W. Damus said:
>
>> Hi,
>>
>> I have a CDO repository with the supportingEcore property set to true,
>> so that I can store UML and Ecore models in legacy mode.
>>
>> When I commit an EPackage (in a CDOResource) to the repository, all of
>> the EStructuralFeatures of its EClasses lose their eType references.
>> When I load the resource again in a new transaction, my EAttributes
>> have no types. For example, an attribute that looks like this in XMI:
>>
>> <eStructuralFeatures xmi:type="ecore:EAttribute"
>> xmi:id="_99Kc9vh2EeG_Su_GArlGLw" name="permanent" ordered="false"
>> lowerBound="1">
>> <eType xmi:type="ecore:EDataType"
>> href="http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
>> </eStructuralFeatures>
>>
>> (using the URI of the registered Ecore package to reference the
>> EBoolean type) ends up with null type in the repository.
>>
>> I thought that supportingEcore should let me store Ecore models in
>> legacy mode, and that references to statically-registered EPackages
>> would be resolved by the resource set as usual in both the server and
>> the client.
>>
>> Am I doing something wrong? Missing something?
>>
>> Thanks,
>>
>> Christian
|
|
|
| Re: [CDO] My EStructuralFeatures lose their eTypes [message #909930 is a reply to message #909784] |
Sat, 08 September 2012 05:01 |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Christian,
I can't comment on CDO, but in general volatile should not have been
part of the Ecore model. It has (should have) no semantic impact. It
should have been part of the GenFeature because it should only affect
the generated code to not declare variables. Mostly that will be
because it's also derived, but one might want to store the value in a
variable of some different type; not a common case.
As for the relation between eType and eGenericType, one isn't strictly
derived from the other, but rather they are mutually derived. The
logic for eIsSet is also tricky; generally, when there are no generic
type parameters or arguments on the generic type, then it can be derived
from the eType so we prefer to serialize and copy that simpler structure
so that serializations don't change until you started to actually
exploit generics.
In any case, I would expect any type of repository storing any type of
model information to generally respect eIsSet and store only those
things considered set. I don't expect any repository to consider
volatile in its storage decisions.
On 07/09/2012 9:32 PM, Christian W. Damus wrote:
> Hmmm . . .
>
> The ETypedElement eType reference and eGenericType containment
> reference are derived from one another. Both are marked as volatile
> but neither is marked as derived in Ecore.ecore. However, the problem
> that I'm seeing is that the EGenericType that references an
> ETypedElement's type is not stored in the repository, or at least it
> isn't loaded back from the repo.
>
> Could CDO be ignoring volatile containment references somewhere?
>
> cW
>
> On 2012-09-07 19:20:37 +0000, Christian W. Damus said:
>
>> Actually, I'm finding that even eType references *within* a single
>> Ecore resource in the repository are lost.
>>
>> The problem isn't restricted to references to types in registered
>> packages.
>>
>> Now I really think I'm doing something wrong. But, my repo has
>> "supportingEcore" enabled and the Ecore EPackage registered and
>> legacy mode turned on. What else could I need?
>>
>> cW
>>
>>
>> On 2012-09-07 16:41:47 +0000, Christian W. Damus said:
>>
>>> Hi,
>>>
>>> I have a CDO repository with the supportingEcore property set to
>>> true, so that I can store UML and Ecore models in legacy mode.
>>>
>>> When I commit an EPackage (in a CDOResource) to the repository, all
>>> of the EStructuralFeatures of its EClasses lose their eType
>>> references. When I load the resource again in a new transaction, my
>>> EAttributes have no types. For example, an attribute that looks
>>> like this in XMI:
>>>
>>> <eStructuralFeatures xmi:type="ecore:EAttribute"
>>> xmi:id="_99Kc9vh2EeG_Su_GArlGLw" name="permanent" ordered="false"
>>> lowerBound="1">
>>> <eType xmi:type="ecore:EDataType"
>>> href="http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
>>> </eStructuralFeatures>
>>>
>>> (using the URI of the registered Ecore package to reference the
>>> EBoolean type) ends up with null type in the repository.
>>>
>>> I thought that supportingEcore should let me store Ecore models in
>>> legacy mode, and that references to statically-registered EPackages
>>> would be resolved by the resource set as usual in both the server
>>> and the client.
>>>
>>> Am I doing something wrong? Missing something?
>>>
>>> Thanks,
>>>
>>> Christian
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
Goto Forum:
Current Time: Sat Apr 27 01:54:03 GMT 2024
Powered by FUDForum. Page generated in 0.03252 seconds |
] 
Search
Help
Register
Login
Home
