Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » "Stale" attribute values on a proxy
"Stale" attribute values on a proxy [message #687527] Tue, 21 June 2011 22:15 Go to next message
Dan Pollitt is currently offline Dan PollittFriend
Messages: 55
Registered: August 2010
Member
In our EMF-based Eclipse application we have an in-memory instance of
the application's domain model that is the preferred location for
application components to interrogate or listen to the model. That model
instance is backed by a single ResourceSet. The application currently
uses xmi serialization to several resource files.

To cope with changes to the persisted model that happen outside of the
in-memory objects (for example by an editor that uses it's own
ResourceSet so that changes made in the editor are isolated until
saved), we recently enhanced the application to listen for workspace
changes to files backing resources in our ResourceSet. When detected
those resources that were modified are unloaded (much like in the
generated sample editor code).

We want to allow parts of the application to retain references to model
objects and be unaware of the concepts of loading/proxying. They should
also be allowed to attach adapters for change notification and expect
those to be active for the life of the application.

The resource unloading gets us part of the way - the referenced model
objects held by the app are set to be proxies, navigating references
from the retained reference after an unload causes the referenced
objects to be resolved, and the newly loaded object's state reflects
that of the latest persistant form. The main problems are around the
retained reference to a now proxy model object:

- The attribute values of this object remain as before the object was
unloaded, these values can now be stale (differ from newer persistent form).
- If a navigation is performed across the model to the "same" object to
which the reference is held (loading as we go) they will be different
objects.

I wanted to see if there was something we were missing to enable us to
both keep references to model objects but also reload them if they
change externally but with the elements of the application holding the
references being ignorant of what's going on behind the scenes. I don't
want them to have to deal with URIs/resolving etc.

One idea that was discussed briefly was wrapping the model object
instances in a delegating proxy object that swapped out the delegate
reference for a new one (and moving across adapters etc) when a
reference or a proerty was accessed and the wrapped instance had been
turned into a proxy. I think this would be relatively simple to do but
don't want to set off down that road if there's just a better way to use
the EMF APIs out of the box.

Looking forward to hearing your thoughts,

Thanks,
Dan
Re: "Stale" attribute values on a proxy [message #687528 is a reply to message #687527] Wed, 22 June 2011 03:09 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30457
Registered: July 2009
Senior Member
Dan,

Comments below.


Dan Pollitt wrote:
> In our EMF-based Eclipse application we have an in-memory instance of
> the application's domain model that is the preferred location for
> application components to interrogate or listen to the model. That
> model instance is backed by a single ResourceSet. The application
> currently uses xmi serialization to several resource files.
>
> To cope with changes to the persisted model that happen outside of the
> in-memory objects (for example by an editor that uses it's own
> ResourceSet so that changes made in the editor are isolated until
> saved), we recently enhanced the application to listen for workspace
> changes to files backing resources in our ResourceSet. When detected
> those resources that were modified are unloaded (much like in the
> generated sample editor code).
>
> We want to allow parts of the application to retain references to
> model objects and be unaware of the concepts of loading/proxying. They
> should also be allowed to attach adapters for change notification and
> expect those to be active for the life of the application.
>
> The resource unloading gets us part of the way - the referenced model
> objects held by the app are set to be proxies, navigating references
> from the retained reference after an unload causes the referenced
> objects to be resolved, and the newly loaded object's state reflects
> that of the latest persistant form. The main problems are around the
> retained reference to a now proxy model object:
>
> - The attribute values of this object remain as before the object was
> unloaded, these values can now be stale (differ from newer persistent
> form).
Definitely. They'll only change if you change them, but that would be
kind of pointless...
> - If a navigation is performed across the model to the "same" object
> to which the reference is held (loading as we go) they will be
> different objects.
Definitely. Proxies are resolved by replacing the reference with a
reference to the actual different resolved object.
>
> I wanted to see if there was something we were missing to enable us to
> both keep references to model objects but also reload them if they
> change externally but with the elements of the application holding the
> references being ignorant of what's going on behind the scenes. I
> don't want them to have to deal with URIs/resolving etc.
Anything that's directly referencing objects will notice that the object
has become a proxy and will need to do something; note that unloading
will remove all adapters on the object, so that's one way to find out
it's time to look for the new resolved replacement.
>
> One idea that was discussed briefly was wrapping the model object
> instances in a delegating proxy object that swapped out the delegate
> reference for a new one (and moving across adapters etc) when a
> reference or a proerty was accessed and the wrapped instance had been
> turned into a proxy. I think this would be relatively simple to do but
> don't want to set off down that road if there's just a better way to
> use the EMF APIs out of the box.
No, that's pretty much the only type of approach.
>
> Looking forward to hearing your thoughts,
>
> Thanks,
> Dan
Re: "Stale" attribute values on a proxy [message #687530 is a reply to message #687528] Wed, 22 June 2011 06:04 Go to previous messageGo to next message
Dan Pollitt is currently offline Dan PollittFriend
Messages: 55
Registered: August 2010
Member
Hi Ed,

Ok - thanks for the quick response, we'll start investigating the
wrapping approach.

Dan

On 22/06/2011 04:09, Ed Merks wrote:
> Dan,
>
> Comments below.
>
>
> Dan Pollitt wrote:
>> In our EMF-based Eclipse application we have an in-memory instance of
>> the application's domain model that is the preferred location for
>> application components to interrogate or listen to the model. That
>> model instance is backed by a single ResourceSet. The application
>> currently uses xmi serialization to several resource files.
>>
>> To cope with changes to the persisted model that happen outside of the
>> in-memory objects (for example by an editor that uses it's own
>> ResourceSet so that changes made in the editor are isolated until
>> saved), we recently enhanced the application to listen for workspace
>> changes to files backing resources in our ResourceSet. When detected
>> those resources that were modified are unloaded (much like in the
>> generated sample editor code).
>>
>> We want to allow parts of the application to retain references to
>> model objects and be unaware of the concepts of loading/proxying. They
>> should also be allowed to attach adapters for change notification and
>> expect those to be active for the life of the application.
>>
>> The resource unloading gets us part of the way - the referenced model
>> objects held by the app are set to be proxies, navigating references
>> from the retained reference after an unload causes the referenced
>> objects to be resolved, and the newly loaded object's state reflects
>> that of the latest persistant form. The main problems are around the
>> retained reference to a now proxy model object:
>>
>> - The attribute values of this object remain as before the object was
>> unloaded, these values can now be stale (differ from newer persistent
>> form).
> Definitely. They'll only change if you change them, but that would be
> kind of pointless...
>> - If a navigation is performed across the model to the "same" object
>> to which the reference is held (loading as we go) they will be
>> different objects.
> Definitely. Proxies are resolved by replacing the reference with a
> reference to the actual different resolved object.
>>
>> I wanted to see if there was something we were missing to enable us to
>> both keep references to model objects but also reload them if they
>> change externally but with the elements of the application holding the
>> references being ignorant of what's going on behind the scenes. I
>> don't want them to have to deal with URIs/resolving etc.
> Anything that's directly referencing objects will notice that the object
> has become a proxy and will need to do something; note that unloading
> will remove all adapters on the object, so that's one way to find out
> it's time to look for the new resolved replacement.
>>
>> One idea that was discussed briefly was wrapping the model object
>> instances in a delegating proxy object that swapped out the delegate
>> reference for a new one (and moving across adapters etc) when a
>> reference or a proerty was accessed and the wrapped instance had been
>> turned into a proxy. I think this would be relatively simple to do but
>> don't want to set off down that road if there's just a better way to
>> use the EMF APIs out of the box.
> No, that's pretty much the only type of approach.
>>
>> Looking forward to hearing your thoughts,
>>
>> Thanks,
>> Dan
Re: "Stale" attribute values on a proxy [message #687531 is a reply to message #687528] Wed, 22 June 2011 06:06 Go to previous message
Dan Pollitt is currently offline Dan PollittFriend
Messages: 55
Registered: August 2010
Member
Hi Ed,

Ok - thanks for the quick response, we'll start investigating the
wrapping approach.

Dan

On 22/06/2011 04:09, Ed Merks wrote:
> Dan,
>
> Comments below.
>
>
> Dan Pollitt wrote:
>> In our EMF-based Eclipse application we have an in-memory instance of
>> the application's domain model that is the preferred location for
>> application components to interrogate or listen to the model. That
>> model instance is backed by a single ResourceSet. The application
>> currently uses xmi serialization to several resource files.
>>
>> To cope with changes to the persisted model that happen outside of the
>> in-memory objects (for example by an editor that uses it's own
>> ResourceSet so that changes made in the editor are isolated until
>> saved), we recently enhanced the application to listen for workspace
>> changes to files backing resources in our ResourceSet. When detected
>> those resources that were modified are unloaded (much like in the
>> generated sample editor code).
>>
>> We want to allow parts of the application to retain references to
>> model objects and be unaware of the concepts of loading/proxying. They
>> should also be allowed to attach adapters for change notification and
>> expect those to be active for the life of the application.
>>
>> The resource unloading gets us part of the way - the referenced model
>> objects held by the app are set to be proxies, navigating references
>> from the retained reference after an unload causes the referenced
>> objects to be resolved, and the newly loaded object's state reflects
>> that of the latest persistant form. The main problems are around the
>> retained reference to a now proxy model object:
>>
>> - The attribute values of this object remain as before the object was
>> unloaded, these values can now be stale (differ from newer persistent
>> form).
> Definitely. They'll only change if you change them, but that would be
> kind of pointless...
>> - If a navigation is performed across the model to the "same" object
>> to which the reference is held (loading as we go) they will be
>> different objects.
> Definitely. Proxies are resolved by replacing the reference with a
> reference to the actual different resolved object.
>>
>> I wanted to see if there was something we were missing to enable us to
>> both keep references to model objects but also reload them if they
>> change externally but with the elements of the application holding the
>> references being ignorant of what's going on behind the scenes. I
>> don't want them to have to deal with URIs/resolving etc.
> Anything that's directly referencing objects will notice that the object
> has become a proxy and will need to do something; note that unloading
> will remove all adapters on the object, so that's one way to find out
> it's time to look for the new resolved replacement.
>>
>> One idea that was discussed briefly was wrapping the model object
>> instances in a delegating proxy object that swapped out the delegate
>> reference for a new one (and moving across adapters etc) when a
>> reference or a proerty was accessed and the wrapped instance had been
>> turned into a proxy. I think this would be relatively simple to do but
>> don't want to set off down that road if there's just a better way to
>> use the EMF APIs out of the box.
> No, that's pretty much the only type of approach.
>>
>> Looking forward to hearing your thoughts,
>>
>> Thanks,
>> Dan
Previous Topic:Translatable EAttribute default values
Next Topic:Common editor for model + model extension
Goto Forum:
  


Current Time: Fri Sep 20 23:08:45 GMT 2019

Powered by FUDForum. Page generated in 0.01970 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top