Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Retaining a reference to a model object
[CDO] Retaining a reference to a model object [message #687537] Wed, 22 June 2011 13:39 Go to next message
Dan Pollitt is currently offline Dan PollittFriend
Messages: 55
Registered: August 2010
Member
Hi,

Yesterday I posted a message ""Stale" attribute values on a proxy",
(that referred to using XMI file persistence) reposted below:

==================
From posting ""Stale" attribute values on a proxy" (21/06/2011):

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.
....
==================

I wanted to understand how my model would behave if it were backed by
CDO? If my model was CDO-powered could I interact with it in the way I
describe above?

Thanks,
Dan
Re: [CDO] Retaining a reference to a model object [message #687565 is a reply to message #687537] Wed, 22 June 2011 18:34 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6445
Registered: July 2009
Senior Member
Hi Dan,

With CDO you could maintain a "permanent" transaction for the application and separate ones for each editor. Each CDO transaction manages an own EMF resource set and an own set of EObjects (only those that are really needed and their modeled state is transparently shared until they are modified). When ever one of these transactions is committed the other transactions transparently update their models and notify their adapters. If I understood you correctly that's more or less what you're looking for, right?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 22.06.2011 15:39, schrieb Dan Pollitt:
> Hi,
>
> Yesterday I posted a message ""Stale" attribute values on a proxy", (that referred to using XMI file persistence) reposted below:
>
> ==================
> From posting ""Stale" attribute values on a proxy" (21/06/2011):
>
> 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.
> ...
> ==================
>
> I wanted to understand how my model would behave if it were backed by CDO? If my model was CDO-powered could I interact with it in the way I describe above?
>
> Thanks,
> Dan


Previous Topic:Generated diagram code does not respect interface name pattern - bug?
Next Topic:[CDO] Recovering from offline mode
Goto Forum:
  


Current Time: Sat Sep 21 03:22:18 GMT 2019

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

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

Back to the top