Home » Modeling » EMF » Unresolved cross-document URIs get corrupted by ordinary editing
| Unresolved cross-document URIs get corrupted by ordinary editing [message #416655] |
Mon, 11 February 2008 11:12  |
 PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
When working with EMF models that span several documents, I observe that
some editing operations cause inconsistent results. This happens with
references that uses URIs that point into another file where the target
object is referenced by its sibling number. If the order of the siblings is
changed, the referencing URIs are not updated. Hence, when the referencing
URIs are later resolved, they will point to the wrong objects.
Currently I have been forced to handle this in the editing commands as
follows:
- Before actually changing the model, resolve all proxies for all affected
URIs
- After the change, reassign all affected references (to force an update of
their URIs)
Not very elegant, I agree.
Is there a mechanism in EMF that I'm unaware of, that is designed to take
care of this problem?
The situation can be reproduced with the EXTLibrary example as follows:
(1) Open extlibrary.genmodel, and set the 'Containment Proxies' property to
'true'
(2) Regenerate the code, and start the generated editor
(3) Create a new file Book1.extlibrary containing a Book object, and name
the Bool Object 'Book One'
(4) Save and close Book1.extlibrary
(4) Create a new file Book2.extlibrary containing a Book object, and name
the Bool Object 'Book Two'
(4) Save and close Book2.extlibrary
(5) Create a new file Library.extlibrary containing a Library object
(6) Add two Writer objects to the Library, and name them 'Firstwriter' and
'Secondwriter'
(7) Use the 'load resource...' command to load Book1.extlibrary and
Book2.extlibrary into the Library editor
(8) Select 'Firstwriter' and set its Books property to 'Book One'
(9) Select 'Secondwriter' and set its Books property to 'Book Two'
(10) Save and close Library.extlibrary
(11) Open Library.extlibrary
(12) Drag Secondwriter in front of Firstwriter
(13) Save and close Library.extlibrary
(14) Open Book1.extlibrary and observe the Author property of 'Book One'. It
has changed from 'Firstwriter' to 'Secondwriter'.
|
|
|
| Re: Unresolved cross-document URIs get corrupted by ordinary editing [message #416665 is a reply to message #416655] |
Mon, 11 February 2008 18:20  |
David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Hi Pal,
In addition to the default, index-based serializing of object
references, EMF supports an alternative: keys based on attribute values.
To use this, you should set the EReference's eKeys reference to one or
more of the target EClass's EAttributes, which will then be used to
uniquely identify any instance within that reference.
This will change the serialization form from @<reference>.<index> to
@<reference>[<key-attribute>='<value>']
So, the serialized reference will be unaffected by reordering, but, of
course, will become brittle to changes in key attribute values.
If this approach doesn't solve your problem, I'm afraid then, yes,
you'll have to resort to ensuring that all referencing resources are
loaded before making any changes and saving them again afterwards.
Cheers,
Dave
Pål Stenslet wrote:
> When working with EMF models that span several documents, I observe that
> some editing operations cause inconsistent results. This happens with
> references that uses URIs that point into another file where the target
> object is referenced by its sibling number. If the order of the siblings
> is changed, the referencing URIs are not updated. Hence, when the
> referencing URIs are later resolved, they will point to the wrong objects.
>
> Currently I have been forced to handle this in the editing commands as
> follows:
> - Before actually changing the model, resolve all proxies for all
> affected URIs
> - After the change, reassign all affected references (to force an update
> of their URIs)
>
> Not very elegant, I agree.
>
> Is there a mechanism in EMF that I'm unaware of, that is designed to
> take care of this problem?
>
> The situation can be reproduced with the EXTLibrary example as follows:
>
> (1) Open extlibrary.genmodel, and set the 'Containment Proxies' property
> to 'true'
> (2) Regenerate the code, and start the generated editor
> (3) Create a new file Book1.extlibrary containing a Book object, and
> name the Bool Object 'Book One'
> (4) Save and close Book1.extlibrary
> (4) Create a new file Book2.extlibrary containing a Book object, and
> name the Bool Object 'Book Two'
> (4) Save and close Book2.extlibrary
> (5) Create a new file Library.extlibrary containing a Library object
> (6) Add two Writer objects to the Library, and name them 'Firstwriter'
> and 'Secondwriter'
> (7) Use the 'load resource...' command to load Book1.extlibrary and
> Book2.extlibrary into the Library editor
> (8) Select 'Firstwriter' and set its Books property to 'Book One'
> (9) Select 'Secondwriter' and set its Books property to 'Book Two'
> (10) Save and close Library.extlibrary
> (11) Open Library.extlibrary
> (12) Drag Secondwriter in front of Firstwriter
> (13) Save and close Library.extlibrary
> (14) Open Book1.extlibrary and observe the Author property of 'Book
> One'. It has changed from 'Firstwriter' to 'Secondwriter'.
>
|
|
|
| Re: Unresolved cross-document URIs get corrupted by ordinary editing [message #416720 is a reply to message #416665] |
Thu, 14 February 2008 08:35 |
PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Thanks, Dave
I was not aware of this. It may help in making the need to update URI less
frequent. However, as you point out, we would still need to perform similar
proxy resolvment and URI update when changing key attribute values.
Regards,
Pål
"Dave Steinberg" <davidms@ca.ibm.com> wrote in message
news:foq3pi$s1a$1@build.eclipse.org...
> Hi Pal,
>
> In addition to the default, index-based serializing of object references,
> EMF supports an alternative: keys based on attribute values. To use this,
> you should set the EReference's eKeys reference to one or more of the
> target EClass's EAttributes, which will then be used to uniquely identify
> any instance within that reference.
>
> This will change the serialization form from @<reference>.<index> to
> @<reference>[<key-attribute>='<value>']
>
> So, the serialized reference will be unaffected by reordering, but, of
> course, will become brittle to changes in key attribute values.
>
> If this approach doesn't solve your problem, I'm afraid then, yes, you'll
> have to resort to ensuring that all referencing resources are loaded
> before making any changes and saving them again afterwards.
>
> Cheers,
> Dave
>
>
> Pål Stenslet wrote:
>> When working with EMF models that span several documents, I observe that
>> some editing operations cause inconsistent results. This happens with
>> references that uses URIs that point into another file where the target
>> object is referenced by its sibling number. If the order of the siblings
>> is changed, the referencing URIs are not updated. Hence, when the
>> referencing URIs are later resolved, they will point to the wrong
>> objects.
>>
>> Currently I have been forced to handle this in the editing commands as
>> follows:
>> - Before actually changing the model, resolve all proxies for all
>> affected URIs
>> - After the change, reassign all affected references (to force an update
>> of their URIs)
>>
>> Not very elegant, I agree.
>>
>> Is there a mechanism in EMF that I'm unaware of, that is designed to take
>> care of this problem?
>>
>> The situation can be reproduced with the EXTLibrary example as follows:
>>
>> (1) Open extlibrary.genmodel, and set the 'Containment Proxies' property
>> to 'true'
>> (2) Regenerate the code, and start the generated editor
>> (3) Create a new file Book1.extlibrary containing a Book object, and name
>> the Bool Object 'Book One'
>> (4) Save and close Book1.extlibrary
>> (4) Create a new file Book2.extlibrary containing a Book object, and name
>> the Bool Object 'Book Two'
>> (4) Save and close Book2.extlibrary
>> (5) Create a new file Library.extlibrary containing a Library object
>> (6) Add two Writer objects to the Library, and name them 'Firstwriter'
>> and 'Secondwriter'
>> (7) Use the 'load resource...' command to load Book1.extlibrary and
>> Book2.extlibrary into the Library editor
>> (8) Select 'Firstwriter' and set its Books property to 'Book One'
>> (9) Select 'Secondwriter' and set its Books property to 'Book Two'
>> (10) Save and close Library.extlibrary
>> (11) Open Library.extlibrary
>> (12) Drag Secondwriter in front of Firstwriter
>> (13) Save and close Library.extlibrary
>> (14) Open Book1.extlibrary and observe the Author property of 'Book One'.
>> It has changed from 'Firstwriter' to 'Secondwriter'.
>>
|
|
|
| Re: Unresolved cross-document URIs get corrupted by ordinary editing [message #416726 is a reply to message #416720] |
Thu, 14 February 2008 14:26 |
Marcelo Paternostro
Messages: 602
Registered: July 2009 |
Senior Member |
|
|
Hi Pal,
A third approach also supported is to mark one of the attributes of your
class as been the "ID" attribute. This ID has to be unique within the
resource in which the object is located or, alternatively, you can go
for a UUID approach (EcoreUtil.generateUUID() can help). Using IDs has
its own problems such modifying the ID after copying or loading the same
resource again (if your application uses these scenarios).
The following posts and link may help:
"How to properly use the UUID feature of EMF" from 7/21/2006 2:25 AM
"Integrating xmi IDs and my model's uuids (mapping resource ID to model
attribute)" from 6/4/2007 1:24 PM
"Attribute ID = true slows down performance" from 5/9/2007 6:41 AM
http://wiki.eclipse.org/index.php/EMF-FAQ#What.27s_the_diffe rence_between_the_methods_useIDs_and_useUUIDs_in_an_XMLResou rceImpl.3F
Cheers,
Marcelo
Pål Stenslet wrote:
> Thanks, Dave
>
> I was not aware of this. It may help in making the need to update URI
> less frequent. However, as you point out, we would still need to perform
> similar proxy resolvment and URI update when changing key attribute values.
>
> Regards,
> Pål
>
> "Dave Steinberg" <davidms@ca.ibm.com> wrote in message
> news:foq3pi$s1a$1@build.eclipse.org...
>> Hi Pal,
>>
>> In addition to the default, index-based serializing of object
>> references, EMF supports an alternative: keys based on attribute
>> values. To use this, you should set the EReference's eKeys reference
>> to one or more of the target EClass's EAttributes, which will then be
>> used to uniquely identify any instance within that reference.
>>
>> This will change the serialization form from @<reference>.<index> to
>> @<reference>[<key-attribute>='<value>']
>>
>> So, the serialized reference will be unaffected by reordering, but, of
>> course, will become brittle to changes in key attribute values.
>>
>> If this approach doesn't solve your problem, I'm afraid then, yes,
>> you'll have to resort to ensuring that all referencing resources are
>> loaded before making any changes and saving them again afterwards.
>>
>> Cheers,
>> Dave
>>
>>
>> Pål Stenslet wrote:
>>> When working with EMF models that span several documents, I observe
>>> that some editing operations cause inconsistent results. This happens
>>> with references that uses URIs that point into another file where the
>>> target object is referenced by its sibling number. If the order of
>>> the siblings is changed, the referencing URIs are not updated. Hence,
>>> when the referencing URIs are later resolved, they will point to the
>>> wrong objects.
>>>
>>> Currently I have been forced to handle this in the editing commands
>>> as follows:
>>> - Before actually changing the model, resolve all proxies for all
>>> affected URIs
>>> - After the change, reassign all affected references (to force an
>>> update of their URIs)
>>>
>>> Not very elegant, I agree.
>>>
>>> Is there a mechanism in EMF that I'm unaware of, that is designed to
>>> take care of this problem?
>>>
>>> The situation can be reproduced with the EXTLibrary example as follows:
>>>
>>> (1) Open extlibrary.genmodel, and set the 'Containment Proxies'
>>> property to 'true'
>>> (2) Regenerate the code, and start the generated editor
>>> (3) Create a new file Book1.extlibrary containing a Book object, and
>>> name the Bool Object 'Book One'
>>> (4) Save and close Book1.extlibrary
>>> (4) Create a new file Book2.extlibrary containing a Book object, and
>>> name the Bool Object 'Book Two'
>>> (4) Save and close Book2.extlibrary
>>> (5) Create a new file Library.extlibrary containing a Library object
>>> (6) Add two Writer objects to the Library, and name them
>>> 'Firstwriter' and 'Secondwriter'
>>> (7) Use the 'load resource...' command to load Book1.extlibrary and
>>> Book2.extlibrary into the Library editor
>>> (8) Select 'Firstwriter' and set its Books property to 'Book One'
>>> (9) Select 'Secondwriter' and set its Books property to 'Book Two'
>>> (10) Save and close Library.extlibrary
>>> (11) Open Library.extlibrary
>>> (12) Drag Secondwriter in front of Firstwriter
>>> (13) Save and close Library.extlibrary
>>> (14) Open Book1.extlibrary and observe the Author property of 'Book
>>> One'. It has changed from 'Firstwriter' to 'Secondwriter'.
>>>
>
|
|
|
| Re: Unresolved cross-document URIs get corrupted by ordinary editing [message #417103 is a reply to message #416726] |
Wed, 27 February 2008 08:38 |
PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
Thanks again for good suggestions. Since we are working with models spanning
several files/directories, we will be stuck with the task of keeping our
referencing URIs up-to-date, e.g. when moving a referenced object to a
different file. We therefore need to carry foreward our currently working
solution of resolving affected proxies before changing the model, and update
the referencing URIs after the change.
However, one problem remains: The only way we have found to actually update
a referencing URI is to reassign the reference. A side-effect of this, is
that change events are fired (for remove+add or unset+set), causing
unnecessary handling in the applivcation.
Is there another way to simply force a referencing URI to be updated (and
persisted) without firing change notifications that can be confused with
editing operations?
Regards,
Pål
"Marcelo Paternostro" <marcelop@ca.ibm.com> wrote in message
news:fp1j1q$djo$2@build.eclipse.org...
> Hi Pal,
>
> A third approach also supported is to mark one of the attributes of your
> class as been the "ID" attribute. This ID has to be unique within the
> resource in which the object is located or, alternatively, you can go for
> a UUID approach (EcoreUtil.generateUUID() can help). Using IDs has its
> own problems such modifying the ID after copying or loading the same
> resource again (if your application uses these scenarios).
>
> The following posts and link may help:
>
> "How to properly use the UUID feature of EMF" from 7/21/2006 2:25 AM
> "Integrating xmi IDs and my model's uuids (mapping resource ID to model
> attribute)" from 6/4/2007 1:24 PM
> "Attribute ID = true slows down performance" from 5/9/2007 6:41 AM
>
> http://wiki.eclipse.org/index.php/EMF-FAQ#What.27s_the_diffe rence_between_the_methods_useIDs_and_useUUIDs_in_an_XMLResou rceImpl.3F
>
> Cheers,
> Marcelo
>
> Pål Stenslet wrote:
>> Thanks, Dave
>>
>> I was not aware of this. It may help in making the need to update URI
>> less frequent. However, as you point out, we would still need to perform
>> similar proxy resolvment and URI update when changing key attribute
>> values.
>>
>> Regards,
>> Pål
>>
>> "Dave Steinberg" <davidms@ca.ibm.com> wrote in message
>> news:foq3pi$s1a$1@build.eclipse.org...
>>> Hi Pal,
>>>
>>> In addition to the default, index-based serializing of object
>>> references, EMF supports an alternative: keys based on attribute values.
>>> To use this, you should set the EReference's eKeys reference to one or
>>> more of the target EClass's EAttributes, which will then be used to
>>> uniquely identify any instance within that reference.
>>>
>>> This will change the serialization form from @<reference>.<index> to
>>> @<reference>[<key-attribute>='<value>']
>>>
>>> So, the serialized reference will be unaffected by reordering, but, of
>>> course, will become brittle to changes in key attribute values.
>>>
>>> If this approach doesn't solve your problem, I'm afraid then, yes,
>>> you'll have to resort to ensuring that all referencing resources are
>>> loaded before making any changes and saving them again afterwards.
>>>
>>> Cheers,
>>> Dave
>>>
>>>
>>> Pål Stenslet wrote:
>>>> When working with EMF models that span several documents, I observe
>>>> that some editing operations cause inconsistent results. This happens
>>>> with references that uses URIs that point into another file where the
>>>> target object is referenced by its sibling number. If the order of the
>>>> siblings is changed, the referencing URIs are not updated. Hence, when
>>>> the referencing URIs are later resolved, they will point to the wrong
>>>> objects.
>>>>
>>>> Currently I have been forced to handle this in the editing commands as
>>>> follows:
>>>> - Before actually changing the model, resolve all proxies for all
>>>> affected URIs
>>>> - After the change, reassign all affected references (to force an
>>>> update of their URIs)
>>>>
>>>> Not very elegant, I agree.
>>>>
>>>> Is there a mechanism in EMF that I'm unaware of, that is designed to
>>>> take care of this problem?
>>>>
>>>> The situation can be reproduced with the EXTLibrary example as follows:
>>>>
>>>> (1) Open extlibrary.genmodel, and set the 'Containment Proxies'
>>>> property to 'true'
>>>> (2) Regenerate the code, and start the generated editor
>>>> (3) Create a new file Book1.extlibrary containing a Book object, and
>>>> name the Bool Object 'Book One'
>>>> (4) Save and close Book1.extlibrary
>>>> (4) Create a new file Book2.extlibrary containing a Book object, and
>>>> name the Bool Object 'Book Two'
>>>> (4) Save and close Book2.extlibrary
>>>> (5) Create a new file Library.extlibrary containing a Library object
>>>> (6) Add two Writer objects to the Library, and name them 'Firstwriter'
>>>> and 'Secondwriter'
>>>> (7) Use the 'load resource...' command to load Book1.extlibrary and
>>>> Book2.extlibrary into the Library editor
>>>> (8) Select 'Firstwriter' and set its Books property to 'Book One'
>>>> (9) Select 'Secondwriter' and set its Books property to 'Book Two'
>>>> (10) Save and close Library.extlibrary
>>>> (11) Open Library.extlibrary
>>>> (12) Drag Secondwriter in front of Firstwriter
>>>> (13) Save and close Library.extlibrary
>>>> (14) Open Book1.extlibrary and observe the Author property of 'Book
>>>> One'. It has changed from 'Firstwriter' to 'Secondwriter'.
>>>>
>>
|
|
|
| Re: Unresolved cross-document URIs get corrupted by ordinary editing [message #417106 is a reply to message #416726] |
Wed, 27 February 2008 08:44 |
PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
Thanks again for good suggestions. Since we are working with models spanning
several files/directories, we will be stuck with the task of keeping our
referencing URIs up-to-date, e.g. when moving a referenced object to a
different file. We therefore need to carry forward our currently working
solution of resolving affected proxies before changing the model, and update
the referencing URIs after the change.
However, one problem remains: The only way we have found to actually update
a referencing URI is to reassign the reference. A side-effect of this, is
that change events are fired (for remove+add or unset+set), causing
unnecessary handling in the application.
Is there another way to simply force a referencing URI to be updated (and
persisted) without firing change notifications that can be confused with
editing operations?
Regards,
Pål
"Marcelo Paternostro" <marcelop@ca.ibm.com> wrote in message
news:fp1j1q$djo$2@build.eclipse.org...
> Hi Pal,
>
> A third approach also supported is to mark one of the attributes of your
> class as been the "ID" attribute. This ID has to be unique within the
> resource in which the object is located or, alternatively, you can go for
> a UUID approach (EcoreUtil.generateUUID() can help). Using IDs has its
> own problems such modifying the ID after copying or loading the same
> resource again (if your application uses these scenarios).
>
> The following posts and link may help:
>
> "How to properly use the UUID feature of EMF" from 7/21/2006 2:25 AM
> "Integrating xmi IDs and my model's uuids (mapping resource ID to model
> attribute)" from 6/4/2007 1:24 PM
> "Attribute ID = true slows down performance" from 5/9/2007 6:41 AM
>
> http://wiki.eclipse.org/index.php/EMF-FAQ#What.27s_the_diffe rence_between_the_methods_useIDs_and_useUUIDs_in_an_XMLResou rceImpl.3F
>
> Cheers,
> Marcelo
>
> Pål Stenslet wrote:
>> Thanks, Dave
>>
>> I was not aware of this. It may help in making the need to update URI
>> less frequent. However, as you point out, we would still need to perform
>> similar proxy resolvment and URI update when changing key attribute
>> values.
>>
>> Regards,
>> Pål
>>
>> "Dave Steinberg" <davidms@ca.ibm.com> wrote in message
>> news:foq3pi$s1a$1@build.eclipse.org...
>>> Hi Pal,
>>>
>>> In addition to the default, index-based serializing of object
>>> references, EMF supports an alternative: keys based on attribute values.
>>> To use this, you should set the EReference's eKeys reference to one or
>>> more of the target EClass's EAttributes, which will then be used to
>>> uniquely identify any instance within that reference.
>>>
>>> This will change the serialization form from @<reference>.<index> to
>>> @<reference>[<key-attribute>='<value>']
>>>
>>> So, the serialized reference will be unaffected by reordering, but, of
>>> course, will become brittle to changes in key attribute values.
>>>
>>> If this approach doesn't solve your problem, I'm afraid then, yes,
>>> you'll have to resort to ensuring that all referencing resources are
>>> loaded before making any changes and saving them again afterwards.
>>>
>>> Cheers,
>>> Dave
>>>
>>>
>>> Pål Stenslet wrote:
>>>> When working with EMF models that span several documents, I observe
>>>> that some editing operations cause inconsistent results. This happens
>>>> with references that uses URIs that point into another file where the
>>>> target object is referenced by its sibling number. If the order of the
>>>> siblings is changed, the referencing URIs are not updated. Hence, when
>>>> the referencing URIs are later resolved, they will point to the wrong
>>>> objects.
>>>>
>>>> Currently I have been forced to handle this in the editing commands as
>>>> follows:
>>>> - Before actually changing the model, resolve all proxies for all
>>>> affected URIs
>>>> - After the change, reassign all affected references (to force an
>>>> update of their URIs)
>>>>
>>>> Not very elegant, I agree.
>>>>
>>>> Is there a mechanism in EMF that I'm unaware of, that is designed to
>>>> take care of this problem?
>>>>
>>>> The situation can be reproduced with the EXTLibrary example as follows:
>>>>
>>>> (1) Open extlibrary.genmodel, and set the 'Containment Proxies'
>>>> property to 'true'
>>>> (2) Regenerate the code, and start the generated editor
>>>> (3) Create a new file Book1.extlibrary containing a Book object, and
>>>> name the Bool Object 'Book One'
>>>> (4) Save and close Book1.extlibrary
>>>> (4) Create a new file Book2.extlibrary containing a Book object, and
>>>> name the Bool Object 'Book Two'
>>>> (4) Save and close Book2.extlibrary
>>>> (5) Create a new file Library.extlibrary containing a Library object
>>>> (6) Add two Writer objects to the Library, and name them 'Firstwriter'
>>>> and 'Secondwriter'
>>>> (7) Use the 'load resource...' command to load Book1.extlibrary and
>>>> Book2.extlibrary into the Library editor
>>>> (8) Select 'Firstwriter' and set its Books property to 'Book One'
>>>> (9) Select 'Secondwriter' and set its Books property to 'Book Two'
>>>> (10) Save and close Library.extlibrary
>>>> (11) Open Library.extlibrary
>>>> (12) Drag Secondwriter in front of Firstwriter
>>>> (13) Save and close Library.extlibrary
>>>> (14) Open Book1.extlibrary and observe the Author property of 'Book
>>>> One'. It has changed from 'Firstwriter' to 'Secondwriter'.
>>>>
>>
|
|
| |
| Re: Unresolved cross-document URIs get corrupted by ordinary editing [message #417196 is a reply to message #417115] |
Fri, 29 February 2008 05:36 |
PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Thanks a lot, Ed!
The new save option took care of updating the URIs on persistent storage,
and saved us the trouble of handling numerous change notifications from
reassigment of affected references.
No, we are not using EcureUtil.resolveAll() at present, but I will look into
it now to see if it can simplify things even more.
Best regards,
Pål
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fq3mdc$f02$1@build.eclipse.org...
Pål,
Once a proxy is resolved, the URI it uses is no longer recorded, so any
attempted to save a resource that reference that object will use whatever
the new URI for that object is. Are you using EcoreUtil.resolveAll to force
all proxies to resolve?
Note that in 2.3 we added this option to Resource.java:
/**
* A save option that can be used only with {@link #save(Map)}
* to specify that the resource is to be saved only if the new contents
* are different from actual contents;
* this compares the bytes in the backing store against the new bytes that
would be saved.
* The value on this option can be either <code>null</code>,
* {@link #OPTION_SAVE_ONLY_IF_CHANGED_FILE_BUFFER},
* or {@link #OPTION_SAVE_ONLY_IF_CHANGED_MEMORY_BUFFER}.
*/
String OPTION_SAVE_ONLY_IF_CHANGED = "SAVE_ONLY_IF_CHANGED";
When we save a resource in the generated editor, we use this option to save
every resource in the resource set. This ensures that if any resource is
referencing an object whose URI has changed, that resource will be saved,
even if the resource itself has not been not directly modified.
Pål Stenslet wrote:
Hi,
Thanks again for good suggestions. Since we are working with models spanning
several files/directories, we will be stuck with the task of keeping our
referencing URIs up-to-date, e.g. when moving a referenced object to a
different file. We therefore need to carry forward our currently working
solution of resolving affected proxies before changing the model, and update
the referencing URIs after the change.
However, one problem remains: The only way we have found to actually update
a referencing URI is to reassign the reference. A side-effect of this, is
that change events are fired (for remove+add or unset+set), causing
unnecessary handling in the application.
Is there another way to simply force a referencing URI to be updated (and
persisted) without firing change notifications that can be confused with
editing operations?
Regards,
Pål
"Marcelo Paternostro" <marcelop@ca.ibm.com> wrote in message
news:fp1j1q$djo$2@build.eclipse.org...
Hi Pal,
A third approach also supported is to mark one of the attributes of your
class as been the "ID" attribute. This ID has to be unique within the
resource in which the object is located or, alternatively, you can go for
a UUID approach (EcoreUtil.generateUUID() can help). Using IDs has its
own problems such modifying the ID after copying or loading the same
resource again (if your application uses these scenarios).
The following posts and link may help:
"How to properly use the UUID feature of EMF" from 7/21/2006 2:25 AM
"Integrating xmi IDs and my model's uuids (mapping resource ID to model
attribute)" from 6/4/2007 1:24 PM
"Attribute ID = true slows down performance" from 5/9/2007 6:41 AM
http://wiki.eclipse.org/index.php/EMF-FAQ#What.27s_the_diffe rence_between_the_methods_useIDs_and_useUUIDs_in_an_XMLResou rceImpl.3F
Cheers,
Marcelo
Pål Stenslet wrote:
Thanks, Dave
I was not aware of this. It may help in making the need to update URI
less frequent. However, as you point out, we would still need to perform
similar proxy resolvment and URI update when changing key attribute
values.
Regards,
Pål
"Dave Steinberg" <davidms@ca.ibm.com> wrote in message
news:foq3pi$s1a$1@build.eclipse.org...
Hi Pal,
In addition to the default, index-based serializing of object
references, EMF supports an alternative: keys based on attribute values.
To use this, you should set the EReference's eKeys reference to one or
more of the target EClass's EAttributes, which will then be used to
uniquely identify any instance within that reference.
This will change the serialization form from @<reference>.<index> to
@<reference>[<key-attribute>='<value>']
So, the serialized reference will be unaffected by reordering, but, of
course, will become brittle to changes in key attribute values.
If this approach doesn't solve your problem, I'm afraid then, yes,
you'll have to resort to ensuring that all referencing resources are
loaded before making any changes and saving them again afterwards.
Cheers,
Dave
Pål Stenslet wrote:
When working with EMF models that span several documents, I observe
that some editing operations cause inconsistent results. This happens
with references that uses URIs that point into another file where the
target object is referenced by its sibling number. If the order of the
siblings is changed, the referencing URIs are not updated. Hence, when
the referencing URIs are later resolved, they will point to the wrong
objects.
Currently I have been forced to handle this in the editing commands as
follows:
- Before actually changing the model, resolve all proxies for all
affected URIs
- After the change, reassign all affected references (to force an
update of their URIs)
Not very elegant, I agree.
Is there a mechanism in EMF that I'm unaware of, that is designed to
take care of this problem?
The situation can be reproduced with the EXTLibrary example as follows:
(1) Open extlibrary.genmodel, and set the 'Containment Proxies'
property to 'true'
(2) Regenerate the code, and start the generated editor
(3) Create a new file Book1.extlibrary containing a Book object, and
name the Bool Object 'Book One'
(4) Save and close Book1.extlibrary
(4) Create a new file Book2.extlibrary containing a Book object, and
name the Bool Object 'Book Two'
(4) Save and close Book2.extlibrary
(5) Create a new file Library.extlibrary containing a Library object
(6) Add two Writer objects to the Library, and name them 'Firstwriter'
and 'Secondwriter'
(7) Use the 'load resource...' command to load Book1.extlibrary and
Book2.extlibrary into the Library editor
(8) Select 'Firstwriter' and set its Books property to 'Book One'
(9) Select 'Secondwriter' and set its Books property to 'Book Two'
(10) Save and close Library.extlibrary
(11) Open Library.extlibrary
(12) Drag Secondwriter in front of Firstwriter
(13) Save and close Library.extlibrary
(14) Open Book1.extlibrary and observe the Author property of 'Book
One'. It has changed from 'Firstwriter' to 'Secondwriter'.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 15:12:29 GMT 2024
Powered by FUDForum. Page generated in 0.04663 seconds |
] 
Search
Help
Register
Login
Home
