Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Handle external changes - determine "changed" resources
Handle external changes - determine "changed" resources [message #991112] Mon, 17 December 2012 06:56 Go to next message
Vlad Gheorghe is currently offline Vlad Gheorghe
Messages: 111
Registered: May 2011
Senior Member

Hello everyone,

In the context of an EMF-based model editor there is the use case that some of the files backing Resources of the editor's ResrourceSet are changed from ourside the editor.
Changes include content change and read-only status change, and can be detected with appropriate framework mechanisms.


One particular scenario is that a change notification arrives for some files, and the in-memory model was changed (since the last load/save) such that the model changes affect objects stored to some of the resources whose associated files' were notified as changed. (You get my point..)
In this case, a well behaved the editor should
- detect this situation
- notify user about it
- propose a "reconciliation"
a) keep own changes, loose external changes
b) discard own changes, reload external changes
c) start a merge of own and external changes (I've seen this in Kate/KDE)

In order to get to a solution, we have the following EMF problem:
How to determine which resources are affected by in-memory changes, from one synchronization point "S0" up to the current state of the model ?

It can be assumed that the editor uses EMF Edit (EditingDomain, CommandStack).

Up to now there seem to be two solutions:
A) Use the CommandStack to determine the affected resources.
- Mark the "synchonization point"
- use the list of commands from the sync point to the top of the stack
- Determine the list of "primary commands" (Add, Remove, Move, Set, .. )
- difficulty because of CompoundCommand, CommandWrapper, OverridableCommand,..
- "derived commands"
- is this a closed set ?
- risk : the user can extend primary commands - and make additional changes
( should be enforced by "design rule" - but this is risky..)

B) Install a EContentAdapter on the model's roots
- receive notifications and keep track of the "dirty" resrouces
- ISSUE: does not support undo/redo

So is there a "EMF standard recipe" for this ?
Anyone else had this type of problem already ?

Thank you for any hints, suggestions or solutions.


Best regards,
Vlad Gheorghe
Re: Handle external changes - determine "changed" resources [message #991171 is a reply to message #991112] Mon, 17 December 2012 10:27 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26014
Registered: July 2009
Senior Member
Vlad,

Comments below.

On 17/12/2012 3:56 AM, Vlad Gheorghe wrote:
>
> Hello everyone,
>
> In the context of an EMF-based model editor there is the use case that
> some of the files backing Resources of the editor's ResrourceSet are
> changed from ourside the editor. Changes include content change and
> read-only status change, and can be detected with appropriate
> framework mechanisms.
>
>
> One particular scenario is that a change notification arrives for some
> files, and the in-memory model was changed (since the last load/save)
> such that the model changes affect objects stored to some of the
> resources whose associated files' were notified as changed. (You get
> my point..)
> In this case, a well behaved the editor should - detect this situation
> - notify user about it - propose a "reconciliation" a) keep own
> changes, loose external changes
> b) discard own changes, reload external changes
> c) start a merge of own and external changes (I've seen this in
> Kate/KDE)
>
> In order to get to a solution, we have the following EMF problem: How
> to determine which resources are affected by in-memory changes, from
> one synchronization point "S0" up to the current state of the model ?
The generated editor has a workspace listener that listens for resource
deltas; have a look at that.
>
> It can be assumed that the editor uses EMF Edit (EditingDomain,
> CommandStack).
>
> Up to now there seem to be two solutions:
> A) Use the CommandStack to determine the affected resources.
> - Mark the "synchonization point"
> - use the list of commands from the sync point to the top of the
> stack - Determine the list of "primary commands" (Add, Remove, Move,
> Set, .. )
> - difficulty because of CompoundCommand, CommandWrapper,
> OverridableCommand,..
> - "derived commands"
> - is this a closed set ?
> - risk : the user can extend primary commands - and make additional
> changes ( should be enforced by "design rule" - but this is
> risky..)
Command.getAffectedObjects should help in general.
>
> B) Install a EContentAdapter on the model's roots
> - receive notifications and keep track of the "dirty" resrouces
> - ISSUE: does not support undo/redo
>
> So is there a "EMF standard recipe" for this ?
> Anyone else had this type of problem already ?
Perhaps a more brute force solution would be easier. I.e., if you look
at the logic for
org.eclipse.emf.ecore.resource.impl.ResourceImpl.saveOnlyIfChangedWithMemoryBuffer(Map<?,
?>) you can see that you could compare the bytes of the new contents in
the workspace to the bytes you'd get if you saved the current in-memory
resource.
>
> Thank you for any hints, suggestions or solutions.
>
>
> Best regards,
> Vlad Gheorghe
>
Re: Handle external changes - determine &quot;changed&quot; resources [message #991407 is a reply to message #991171] Tue, 18 December 2012 17:40 Go to previous messageGo to next message
Vlad Gheorghe is currently offline Vlad Gheorghe
Messages: 111
Registered: May 2011
Senior Member
Hello Ed,

Thanks a lot for the reply.

Please find my comments inline.


On Mon, Dec 17, 2012 at 5:31 PM, <webmaster@eclipse.org> wrote:
>
> Subject: Re: Handle external changes - determine &quot;changed&quot; resources Author: Ed Merks Date: Mon, 17 December 2012 10:27
> Vlad,
>
> Comments below.
>
> On 17/12/2012 3:56 AM, Vlad Gheorghe wrote:
> >
> > Hello everyone,
> >
> > In the context of an EMF-based model editor there is the use case that
> > some of the files backing Resources of the editor's ResrourceSet are
> > changed from ourside the editor. Changes include content change and
> > read-only status change, and can be detected with appropriate
> > framework mechanisms.
> >
> >
> > One particular scenario is that a change notification arrives for some
> > files, and the in-memory model was changed (since the last load/save)
> > such that the model changes affect objects stored to some of the
> > resources whose associated files' were notified as changed. (You get
> > my point..)
> > In this case, a well behaved the editor should - detect this situation
> > - notify user about it - propose a "reconciliation" a) keep own
> > changes, loose external changes
> > b) discard own changes, reload external changes
> > c) start a merge of own and external changes (I've seen this in
> > Kate/KDE)
> >
> > In order to get to a solution, we have the following EMF problem: How
> > to determine which resources are affected by in-memory changes, from
> > one synchronization point "S0" up to the current state of the model ?
> The generated editor has a workspace listener that listens for resource
> deltas; have a look at that.

Yes, one can receive resource change notifications from IWorkspace.

The question phrasing is misleading.

By "in-memory changes" I meant changes to the model ( as opposed to
file contents changes, which
get notified by IWorkspace as IResourceChangeEvent/IResourceDeltas).



> >
> > It can be assumed that the editor uses EMF Edit (EditingDomain,
> > CommandStack).
> >
> > Up to now there seem to be two solutions:
> > A) Use the CommandStack to determine the affected resources.
> > - Mark the "synchonization point"
> > - use the list of commands from the sync point to the top of the
> > stack - Determine the list of "primary commands" (Add, Remove, Move,
> > Set, .. )
> > - difficulty because of CompoundCommand, CommandWrapper,
> > OverridableCommand,..
> > - "derived commands"
> > - is this a closed set ?
> > - risk : the user can extend primary commands - and make additional
> > changes ( should be enforced by "design rule" - but this is
> > risky..)
> Command.getAffectedObjects should help in general.

I understand that it's main purpose is targeted at UI functionality
(present to the user the remaining objects which are affected by the
command).

I guess that this cannot be used to accurately answer the question
above (hence the "in general" qualifier Smile )


> >
> > B) Install a EContentAdapter on the model's roots
> > - receive notifications and keep track of the "dirty" resrouces
> > - ISSUE: does not support undo/redo
> >
> > So is there a "EMF standard recipe" for this ?
> > Anyone else had this type of problem already ?
> Perhaps a more brute force solution would be easier. I.e., if you look
> at the logic for
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.saveOnlyIfChangedWithMemoryBuffer(Map<?,
> ?>) you can see that you could compare the bytes of the new contents in
> the workspace to the bytes you'd get if you saved the current in-memory
> resource.

That looks like the most promising path to a solution !
So you suggest to detect the "affected resource" at serialization
level, and not at model level.

In our case, this would mean that at each "synchronization point"
(i.e. full load or full save of the resrouce set), a snapshot of the
files'
images is also made.
Then, when the Resource Change Notification is received, each resource
is serialized from the current model state, and compared to the
snapshot.
The differing resources are the ones "affected by in-memory changes".


Thanks again, Ed !


With the best regards


Vlad Gheorghe
Re: Handle external changes - determine &amp;quot;changed&amp;quot; resources [message #991416 is a reply to message #991407] Tue, 18 December 2012 19:35 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26014
Registered: July 2009
Senior Member
Vlad,

Comments below.

On 18/12/2012 2:40 PM, Vlad Gheorghe wrote:
> Hello Ed,
>
> Thanks a lot for the reply.
>
> Please find my comments inline.
>
>
> On Mon, Dec 17, 2012 at 5:31 PM, <mailto:webmaster@xxxxxxxx> wrote:
>>
>> Subject: Re: Handle external changes - determine "changed" resources
>> Author: Ed Merks Date: Mon, 17 December 2012 10:27
>> Vlad,
>>
>> Comments below.
>>
>> On 17/12/2012 3:56 AM, Vlad Gheorghe wrote:
>> >
>> > Hello everyone,
>> >
>> > In the context of an EMF-based model editor there is the use case that
>> > some of the files backing Resources of the editor's ResrourceSet are
>> > changed from ourside the editor. Changes include content change and
>> > read-only status change, and can be detected with appropriate
>> > framework mechanisms.
>> >
>> >
>> > One particular scenario is that a change notification arrives for some
>> > files, and the in-memory model was changed (since the last load/save)
>> > such that the model changes affect objects stored to some of the
>> > resources whose associated files' were notified as changed. (You get
>> > my point..)
>> > In this case, a well behaved the editor should - detect this situation
>> > - notify user about it - propose a "reconciliation" a) keep own
>> > changes, loose external changes
>> > b) discard own changes, reload external changes
>> > c) start a merge of own and external changes (I've seen this in
>> > Kate/KDE)
>> >
>> > In order to get to a solution, we have the following EMF problem: How
>> > to determine which resources are affected by in-memory changes, from
>> > one synchronization point "S0" up to the current state of the model ?
>> The generated editor has a workspace listener that listens for resource
>> deltas; have a look at that.
>
> Yes, one can receive resource change notifications from IWorkspace.
>
> The question phrasing is misleading.
>
> By "in-memory changes" I meant changes to the model ( as opposed to
> file contents changes, which
> get notified by IWorkspace as IResourceChangeEvent/IResourceDeltas).
So I'm not sure what the question is... You can use an EContentAdapter
to listen to everything. You can listen to the command stack change...
>
>
>
>> >
>> > It can be assumed that the editor uses EMF Edit (EditingDomain,
>> > CommandStack).
>> >
>> > Up to now there seem to be two solutions:
>> > A) Use the CommandStack to determine the affected resources.
>> > - Mark the "synchonization point"
>> > - use the list of commands from the sync point to the top of the
>> > stack - Determine the list of "primary commands" (Add, Remove, Move,
>> > Set, .. )
>> > - difficulty because of CompoundCommand, CommandWrapper,
>> > OverridableCommand,..
>> > - "derived commands"
>> > - is this a closed set ?
>> > - risk : the user can extend primary commands - and make additional
>> > changes ( should be enforced by "design rule" - but this is
>> > risky..)
>> Command.getAffectedObjects should help in general.
>
> I understand that it's main purpose is targeted at UI functionality
> (present to the user the remaining objects which are affected by the
> command).
>
> I guess that this cannot be used to accurately answer the question
> above (hence the "in general" qualifier :) )
You could try it....
>
>
>> >
>> > B) Install a EContentAdapter on the model's roots
>> > - receive notifications and keep track of the "dirty" resrouces
>> > - ISSUE: does not support undo/redo
>> >
>> > So is there a "EMF standard recipe" for this ?
>> > Anyone else had this type of problem already ?
>> Perhaps a more brute force solution would be easier. I.e., if you look
>> at the logic for
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.saveOnlyIfChangedWithMemoryBuffer(Map<?,
>>
>> ?>) you can see that you could compare the bytes of the new contents in
>> the workspace to the bytes you'd get if you saved the current in-memory
>> resource.
>
> That looks like the most promising path to a solution !
> So you suggest to detect the "affected resource" at serialization
> level, and not at model level.
I'm not entirely sure I've understood your scenario.
>
> In our case, this would mean that at each "synchronization point"
> (i.e. full load or full save of the resrouce set), a snapshot of the
> files'
> images is also made.
The command stack's dirty state isn't enough?
> Then, when the Resource Change Notification is received, each resource
> is serialized from the current model state, and compared to the
> snapshot.
Wouldn't you just compare the current state with the state of the
underlying file system?
> The differing resources are the ones "affected by in-memory changes".
I think I'm starting to understand. If some resource changes in the
file system, you'd like to know if that particular resource has been
modified in the resource set.

Perhaps something you could try first is to have a specialized command
stack where you can access the list of command and add a helper method
getAffectedResources where you iterate over the commandList from
saveIndex to top, call getAffectedObjects for each one,
AdapterFactoryEditingDomain.unwrap it and get the eResource for each one
and use that to determine the affected resources. That should
generally do the trick with the basic commands provided by EMF.Edit...
>
>
> Thanks again, Ed !
>
>
> With the best regards
>
>
> Vlad Gheorghe
Re: Handle external changes - determine "changed" resources [message #991453 is a reply to message #991112] Wed, 19 December 2012 03:59 Go to previous message
Mikael Barbero is currently offline Mikael Barbero
Messages: 53
Registered: July 2009
Member
Hi Vlad,

It seems that what you want to do is something like described in this post: http://model-driven-blogging.blogspot.fr/2011/12/do-you-want-to-discard-this-editors.html

It's one year old and EMF Compare has evolved since then but the principle seems to describe your use case. The code was for EMF Compare 1.x and it is not functional anymore with version 2.x as it is a rewrite from scratch. If you want to do it with EMF Compare 2.1 stream (the one that will be in Kepler), we would be glad to help you do so.


Best regards,

Mikael Barbero
Obeo

[Updated on: Wed, 19 December 2012 04:01]

Report message to a moderator

Previous Topic:[CDO] Problem with Hibernate example
Next Topic:@ForeignKey annotation not working in all cases
Goto Forum:
  


Current Time: Sat Aug 30 00:33:41 EDT 2014

Powered by FUDForum. Page generated in 0.01771 seconds