Eclipse Community Forums: EMF » Re: EMF model editing /persistence in a "typical" RCP/IDE app

Help

Home

Home » Modeling » EMF » Re: EMF model editing /persistence in a "typical" RCP/IDE app

Show: Today's Messages :: Show Polls :: Message Navigator

Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686687]

Mon, 09 May 2011 20:46

Dan Pollitt

Messages: 55
Registered: August 2010

Member

Hi Tom,

Thanks for your comments - I guess xmi based persistence is unlikely to
be our end-state.

Do you think that there is a natural progression from XMI -> Teneo ->
CDO? Ideally the majority of our application can be unaware of the exact
persistence mechanism.

Dan

On 09/05/2011 11:22, Tom Schindl wrote:
> Am 09.05.11 01:01, schrieb Dan Pollitt:
>> Hi,
>>
>> I have a few questions relating to how one should (or typically would)
>> approach the usage of EMF persistence mechanisms (ResourceSet, Resource)
>> as well as command based editing mechanisms (EditingDomain) within an
>> Eclipse application where I would like to have specialised editors for
>> certain model elements/sub graphs within a model. Assuming default
>> XMI-based local file/workspace persistence.
>>
>
> The problem with that is with XMI-Persistence that there's an all or
> nothing serialisation approach.
>
> Let's assume the following scenario:
> a) Editor A shows subgraph resource:/myfile.xmi/root/company
> b) Editor B shows subgraph resource:/myfile.xmi/root/persons
>
> Now let's also assume both of them are dirty at the same time which
> means for you that saving Editor A, has to save also Editor B which
> probably not what the user will expect.
>
>> I'll use the library model example
>> (http://wiki.eclipse.org/Example_library_EMF_model) to illustrate what
>> I'd like to be able to do:
>>
>> 1. Create a library model instance within a workspace project, a user
>> would think of a workspace project as 1:1 with a Library.
>>
>> 2. Access a library model as part of extensions to the common navigator
>> framework (CNF), to show and react to changes to model structure under a
>> workspace project (as opposed to file system resources) as a tree in the
>> Project Explorer view.
>>
>> 3. Open an editor to edit a subset of a library model instance, e.g. a
>> Book or a Writer, edits should have undo/redo support and saving a dirty
>> Book editor should persist the Book instance.
>>
>>
>> Questions
>> ---------
>>
>> a. As I have read: "a resource is the basic unit of persistence in EMF"
>> - so does that mean that an Eclipse editor needs to operate at the level
>> of a resource? i.e. for a Book editor, I'd need to enable cross-resource
>> containment and make sure Books were created in their own resource?
>>
>
> See above which describes exactly this problem. I think you should think
> about an alternate storage technology. CDO and/or Teneo can help you
> working on the different subgraphs at the same time. CDO even handles
> the syncing automagically.
>
>> b. Is a ResourceSet an appropriate tool to use to restrict the
>> visibility of changes before persisting them to disk? An example might
>> be: I open an editor for a Book and make some changes. Before saving the
>> editor I can see the effects in the editors copy of the model but
>> nowhere else - after saving other in-memory copies of the model (e.g the
>> content provider for the CNF viewer) can react, presumuably by
>> monitoring the workspace resources?
>
> Yes that would be a possibility. IIRC there's been work done to decouple
> the information from the changerecorder to apply it to another resource
> which might be handy when transfering deltas over the wire
>
>>
>> c. I'm imagining that for parts of the application that just need to
>> interrogate/read/observe the model there would be some single place to
>> go to get references into a "golden copy" (i.e. only contain data that
>> has been read from a persistent source) of the model - is that a pattern
>> that people have used and might recommend?
>>
>>
>>
>> I have implementations of an EMF-backed CNF viewer, custom editors
>> (based on code from generated editors) etc - I'm really looking for
>> advice and/or patterns regarding how people have approached the
>> persistence/editing areas - When would you share/create a new
>> ResourceSet/EditingDomain? What are some of the strategies for detecting
>> change conflicts in a resource? For a given model element instance would
>> you only expect to have one in-memory object for it in the VM?
>>
>> I can only hope someone is writing a book that sits on-top of the EMF
>> bible, maybe a "Building Eclipse applications with EMF"... :o)
>>
>>
>> Many thanks,
>> Dan
>

Report message to a moderator

Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686688 is a reply to message #686687]

Mon, 09 May 2011 20:49

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

Yes. Persistence is something you can completely hide from your editor
and your UI-Code does not change in any way when switching to Teneo or CDO.

Tom

Am 09.05.11 22:46, schrieb Dan Pollitt:
> Hi Tom,
>
> Thanks for your comments - I guess xmi based persistence is unlikely to
> be our end-state.
>
> Do you think that there is a natural progression from XMI -> Teneo ->
> CDO? Ideally the majority of our application can be unaware of the exact
> persistence mechanism.
>
> Dan
>
> On 09/05/2011 11:22, Tom Schindl wrote:
>> Am 09.05.11 01:01, schrieb Dan Pollitt:
>>> Hi,
>>>
>>> I have a few questions relating to how one should (or typically would)
>>> approach the usage of EMF persistence mechanisms (ResourceSet, Resource)
>>> as well as command based editing mechanisms (EditingDomain) within an
>>> Eclipse application where I would like to have specialised editors for
>>> certain model elements/sub graphs within a model. Assuming default
>>> XMI-based local file/workspace persistence.
>>>
>>
>> The problem with that is with XMI-Persistence that there's an all or
>> nothing serialisation approach.
>>
>> Let's assume the following scenario:
>> a) Editor A shows subgraph resource:/myfile.xmi/root/company
>> b) Editor B shows subgraph resource:/myfile.xmi/root/persons
>>
>> Now let's also assume both of them are dirty at the same time which
>> means for you that saving Editor A, has to save also Editor B which
>> probably not what the user will expect.
>>
>>> I'll use the library model example
>>> (http://wiki.eclipse.org/Example_library_EMF_model) to illustrate what
>>> I'd like to be able to do:
>>>
>>> 1. Create a library model instance within a workspace project, a user
>>> would think of a workspace project as 1:1 with a Library.
>>>
>>> 2. Access a library model as part of extensions to the common navigator
>>> framework (CNF), to show and react to changes to model structure under a
>>> workspace project (as opposed to file system resources) as a tree in the
>>> Project Explorer view.
>>>
>>> 3. Open an editor to edit a subset of a library model instance, e.g. a
>>> Book or a Writer, edits should have undo/redo support and saving a dirty
>>> Book editor should persist the Book instance.
>>>
>>>
>>> Questions
>>> ---------
>>>
>>> a. As I have read: "a resource is the basic unit of persistence in EMF"
>>> - so does that mean that an Eclipse editor needs to operate at the level
>>> of a resource? i.e. for a Book editor, I'd need to enable cross-resource
>>> containment and make sure Books were created in their own resource?
>>>
>>
>> See above which describes exactly this problem. I think you should think
>> about an alternate storage technology. CDO and/or Teneo can help you
>> working on the different subgraphs at the same time. CDO even handles
>> the syncing automagically.
>>
>>> b. Is a ResourceSet an appropriate tool to use to restrict the
>>> visibility of changes before persisting them to disk? An example might
>>> be: I open an editor for a Book and make some changes. Before saving the
>>> editor I can see the effects in the editors copy of the model but
>>> nowhere else - after saving other in-memory copies of the model (e.g the
>>> content provider for the CNF viewer) can react, presumuably by
>>> monitoring the workspace resources?
>>
>> Yes that would be a possibility. IIRC there's been work done to decouple
>> the information from the changerecorder to apply it to another resource
>> which might be handy when transfering deltas over the wire
>>
>>>
>>> c. I'm imagining that for parts of the application that just need to
>>> interrogate/read/observe the model there would be some single place to
>>> go to get references into a "golden copy" (i.e. only contain data that
>>> has been read from a persistent source) of the model - is that a pattern
>>> that people have used and might recommend?
>>>
>>>
>>>
>>> I have implementations of an EMF-backed CNF viewer, custom editors
>>> (based on code from generated editors) etc - I'm really looking for
>>> advice and/or patterns regarding how people have approached the
>>> persistence/editing areas - When would you share/create a new
>>> ResourceSet/EditingDomain? What are some of the strategies for detecting
>>> change conflicts in a resource? For a given model element instance would
>>> you only expect to have one in-memory object for it in the VM?
>>>
>>> I can only hope someone is writing a book that sits on-top of the EMF
>>> bible, maybe a "Building Eclipse applications with EMF"... :o)
>>>
>>>
>>> Many thanks,
>>> Dan
>>
>

Report message to a moderator

Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686697 is a reply to message #686687]

Tue, 10 May 2011 07:57

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 09.05.2011 22:46, schrieb Dan Pollitt:
> Hi Tom,
>
> Thanks for your comments - I guess xmi based persistence is unlikely to be our end-state.
>
> Do you think that there is a natural progression from XMI -> Teneo -> CDO? Ideally the majority of our application can be unaware of the exact persistence mechanism.
As Tom said, the persistence mechanism of CDO is (can be) statically transparent to your application. In practice, however, you may encounter some different characteristics that will have an impact on typical applications. E.g. the distributed shared nature of CDO managed models can introduce some subtle challenges. Remote deletions are an example. Fortunately most of these aspects are completely configurable so that you can start without passive updates and later switch on more features if you like.

Cheers
/Eike

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

>
> Dan
>
> On 09/05/2011 11:22, Tom Schindl wrote:
>> Am 09.05.11 01:01, schrieb Dan Pollitt:
>>> Hi,
>>>
>>> I have a few questions relating to how one should (or typically would)
>>> approach the usage of EMF persistence mechanisms (ResourceSet, Resource)
>>> as well as command based editing mechanisms (EditingDomain) within an
>>> Eclipse application where I would like to have specialised editors for
>>> certain model elements/sub graphs within a model. Assuming default
>>> XMI-based local file/workspace persistence.
>>>
>>
>> The problem with that is with XMI-Persistence that there's an all or
>> nothing serialisation approach.
>>
>> Let's assume the following scenario:
>> a) Editor A shows subgraph resource:/myfile.xmi/root/company
>> b) Editor B shows subgraph resource:/myfile.xmi/root/persons
>>
>> Now let's also assume both of them are dirty at the same time which
>> means for you that saving Editor A, has to save also Editor B which
>> probably not what the user will expect.
>>
>>> I'll use the library model example
>>> (http://wiki.eclipse.org/Example_library_EMF_model) to illustrate what
>>> I'd like to be able to do:
>>>
>>> 1. Create a library model instance within a workspace project, a user
>>> would think of a workspace project as 1:1 with a Library.
>>>
>>> 2. Access a library model as part of extensions to the common navigator
>>> framework (CNF), to show and react to changes to model structure under a
>>> workspace project (as opposed to file system resources) as a tree in the
>>> Project Explorer view.
>>>
>>> 3. Open an editor to edit a subset of a library model instance, e.g. a
>>> Book or a Writer, edits should have undo/redo support and saving a dirty
>>> Book editor should persist the Book instance.
>>>
>>>
>>> Questions
>>> ---------
>>>
>>> a. As I have read: "a resource is the basic unit of persistence in EMF"
>>> - so does that mean that an Eclipse editor needs to operate at the level
>>> of a resource? i.e. for a Book editor, I'd need to enable cross-resource
>>> containment and make sure Books were created in their own resource?
>>>
>>
>> See above which describes exactly this problem. I think you should think
>> about an alternate storage technology. CDO and/or Teneo can help you
>> working on the different subgraphs at the same time. CDO even handles
>> the syncing automagically.
>>
>>> b. Is a ResourceSet an appropriate tool to use to restrict the
>>> visibility of changes before persisting them to disk? An example might
>>> be: I open an editor for a Book and make some changes. Before saving the
>>> editor I can see the effects in the editors copy of the model but
>>> nowhere else - after saving other in-memory copies of the model (e.g the
>>> content provider for the CNF viewer) can react, presumuably by
>>> monitoring the workspace resources?
>>
>> Yes that would be a possibility. IIRC there's been work done to decouple
>> the information from the changerecorder to apply it to another resource
>> which might be handy when transfering deltas over the wire
>>
>>>
>>> c. I'm imagining that for parts of the application that just need to
>>> interrogate/read/observe the model there would be some single place to
>>> go to get references into a "golden copy" (i.e. only contain data that
>>> has been read from a persistent source) of the model - is that a pattern
>>> that people have used and might recommend?
>>>
>>>
>>>
>>> I have implementations of an EMF-backed CNF viewer, custom editors
>>> (based on code from generated editors) etc - I'm really looking for
>>> advice and/or patterns regarding how people have approached the
>>> persistence/editing areas - When would you share/create a new
>>> ResourceSet/EditingDomain? What are some of the strategies for detecting
>>> change conflicts in a resource? For a given model element instance would
>>> you only expect to have one in-memory object for it in the VM?
>>>
>>> I can only hope someone is writing a book that sits on-top of the EMF
>>> bible, maybe a "Building Eclipse applications with EMF"... :o)
>>>
>>>
>>> Many thanks,
>>> Dan
>>
>

Cheers
/Eike

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

Report message to a moderator