|
| Re: [CDO] Retaining a reference to a model object [message #687565 is a reply to message #687537] |
Wed, 22 June 2011 18:34  |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03015 seconds
] 
Search
Help
Register
Login
Home
