Home » Modeling » EMF » Handle external changes - determine "changed" resources
| Handle external changes - determine "changed" resources [message #991112] |
Mon, 17 December 2012 11:56  |
 Vlad Gheorghe
Messages: 127
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 15:27  |
Ed Merks
Messages: 33140
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Handle external changes - determine "changed" resources [message #991407 is a reply to message #991171] |
Tue, 18 December 2012 22:40 |
Vlad Gheorghe
Messages: 127
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 "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).
> >
> > 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  )
> >
> > 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 &quot;changed&quot; resources [message #991416 is a reply to message #991407] |
Wed, 19 December 2012 00:35 |
Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 17:26:40 GMT 2024
Powered by FUDForum. Page generated in 0.05068 seconds |
] 
Search
Help
Register
Login
Home
