Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMFStore] command stack flushing
[EMFStore] command stack flushing [message #1179081] Sun, 10 November 2013 03:21 Go to next message
Scott Dybiec is currently offline Scott DybiecFriend
Messages: 133
Registered: July 2009
Senior Member
When saving an XMI file-based Resource, the CommandStack is not flushed
on save, so the user in many cases is able to undo changes made as far
back as the time when the file was first loaded, regardless of when it
was saved.

When my application uses EMFStore, the CommandStack is flushed on every
commit, so undo/redo is no longer possible on the local copy after a
commit. This flushing is done in the ESCommitObserver in
ESWorkspaceProviderImpl.

I'd like my application's users to be able to undo and redo changes to
their local copies even after a commit. Is this possible? Can this flush
of the CommandStack be eliminated, and, if so, how?


/**
*
* {@inheritDoc}
*
* @see
org.eclipse.emf.emfstore.client.observer.ESCommitObserver#commitCompleted(org.eclipse.emf.emfstore.client.ESLocalProject,
*
org.eclipse.emf.emfstore.server.model.versionspec.ESPrimaryVersionSpec,
* org.eclipse.core.runtime.IProgressMonitor)
*/
public void commitCompleted(ESLocalProject project,
ESPrimaryVersionSpec newRevision, IProgressMonitor monitor) {
flushCommandStack();
}
Re: [EMFStore] command stack flushing [message #1180965 is a reply to message #1179081] Mon, 11 November 2013 09:23 Go to previous messageGo to next message
Edgar Mueller is currently offline Edgar MuellerFriend
Messages: 72
Registered: March 2011
Member
Hi Scott,

EMFStore doesn't support undo/redo after commit/update, because you are
likely to get inconsistent states on your command stack when trying to
perform an undo after incoming changes have been applied. For instance,
consider the case where a conflict arises. In case you resolve the
conflict by choosing to apply the incoming changes, those changes would
not have a represenentation on the command stack, i.e. you can not undo
incoming changes. So, let's assume that undo would undo only your most
recent local change. But then again, what if the model instance you
edited just got deleted by the conflict resolution? A undo isn't
possible since the model instance does not exist anymore.

I hope this helps to see why we choosed to flush the command stack upon
commit/update.

Cheers,
Edgar

> I'd like my application's users to be able to undo and redo changes to
> their local copies even after a commit. Is this possible? Can this flush
> of the CommandStack be eliminated, and, if so, how?


--
Edgar Mueller

Get Professional Eclipse Support: http://eclipsesource.com/munich
Re: [EMFStore] command stack flushing [message #1181790 is a reply to message #1180965] Mon, 11 November 2013 21:05 Go to previous messageGo to next message
Scott Dybiec is currently offline Scott DybiecFriend
Messages: 133
Registered: July 2009
Senior Member
Thanks, Edgar. That helps. I get it now. Appreciate your explanation.

On 11/11/2013 4:23 AM, Edgar Mueller wrote:
> Hi Scott,
>
> EMFStore doesn't support undo/redo after commit/update, because you are
> likely to get inconsistent states on your command stack when trying to
> perform an undo after incoming changes have been applied. For instance,
> consider the case where a conflict arises. In case you resolve the
> conflict by choosing to apply the incoming changes, those changes would
> not have a represenentation on the command stack, i.e. you can not undo
> incoming changes. So, let's assume that undo would undo only your most
> recent local change. But then again, what if the model instance you
> edited just got deleted by the conflict resolution? A undo isn't
> possible since the model instance does not exist anymore.
>
> I hope this helps to see why we choosed to flush the command stack upon
> commit/update.
>
> Cheers,
> Edgar
>
>> I'd like my application's users to be able to undo and redo changes to
>> their local copies even after a commit. Is this possible? Can this flush
>> of the CommandStack be eliminated, and, if so, how?
>
>
Re: [EMFStore] command stack flushing [message #1694119 is a reply to message #1180965] Thu, 30 April 2015 16:00 Go to previous messageGo to next message
Scott Dybiec is currently offline Scott DybiecFriend
Messages: 133
Registered: July 2009
Senior Member
Edgar,

I have a follow-up question to this old thread.

I understand now that undo/redo can cause inconsistent states when
conflict detection makes changes to local data.

In my application I've implemented a simple, headless conflict
resolution strategy --- commit my changes, reject their changes.
Essentially, last write wins.

With this simple rule applied to all updates to the EMFStore server, is
there any way undo/redo could cause an inconsistent state of the data?

$cott

On 11/11/2013 4:23 AM, Edgar Mueller wrote:
> Hi Scott,
>
> EMFStore doesn't support undo/redo after commit/update, because you are
> likely to get inconsistent states on your command stack when trying to
> perform an undo after incoming changes have been applied. For instance,
> consider the case where a conflict arises. In case you resolve the
> conflict by choosing to apply the incoming changes, those changes would
> not have a represenentation on the command stack, i.e. you can not undo
> incoming changes. So, let's assume that undo would undo only your most
> recent local change. But then again, what if the model instance you
> edited just got deleted by the conflict resolution? A undo isn't
> possible since the model instance does not exist anymore.
>
> I hope this helps to see why we choosed to flush the command stack upon
> commit/update.
>
> Cheers,
> Edgar
>
>> I'd like my application's users to be able to undo and redo changes to
>> their local copies even after a commit. Is this possible? Can this flush
>> of the CommandStack be eliminated, and, if so, how?
>
>
Re: [EMFStore] command stack flushing [message #1694726 is a reply to message #1694119] Thu, 07 May 2015 12:27 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 249
Registered: July 2009
Senior Member
Hi Scott,

I am sorry for the delayed reply. We are currently swamped with customer
work.
Edgar will get back to you tomorrow.

Cheers,
Maximilian

Am 30.04.2015 um 18:00 schrieb Scott Dybiec:
> Edgar,
>
> I have a follow-up question to this old thread.
>
> I understand now that undo/redo can cause inconsistent states when
> conflict detection makes changes to local data.
>
> In my application I've implemented a simple, headless conflict
> resolution strategy --- commit my changes, reject their changes.
> Essentially, last write wins.
>
> With this simple rule applied to all updates to the EMFStore server, is
> there any way undo/redo could cause an inconsistent state of the data?
>
> $cott
>
> On 11/11/2013 4:23 AM, Edgar Mueller wrote:
>> Hi Scott,
>>
>> EMFStore doesn't support undo/redo after commit/update, because you are
>> likely to get inconsistent states on your command stack when trying to
>> perform an undo after incoming changes have been applied. For instance,
>> consider the case where a conflict arises. In case you resolve the
>> conflict by choosing to apply the incoming changes, those changes would
>> not have a represenentation on the command stack, i.e. you can not undo
>> incoming changes. So, let's assume that undo would undo only your most
>> recent local change. But then again, what if the model instance you
>> edited just got deleted by the conflict resolution? A undo isn't
>> possible since the model instance does not exist anymore.
>>
>> I hope this helps to see why we choosed to flush the command stack upon
>> commit/update.
>>
>> Cheers,
>> Edgar
>>
>>> I'd like my application's users to be able to undo and redo changes to
>>> their local copies even after a commit. Is this possible? Can this flush
>>> of the CommandStack be eliminated, and, if so, how?
>>
>>
>


--
Maximilian Kögel

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
Re: [EMFStore] command stack flushing [message #1695082 is a reply to message #1694119] Mon, 11 May 2015 21:04 Go to previous message
Edgar Mueller is currently offline Edgar MuellerFriend
Messages: 72
Registered: March 2011
Member
Hi Scott,

once again, sorry for the delay.

To answer your question: it depends on the implementation of your
undo/redo mechanism. If you re-record changes things should be fine, but
if you use the recorded operations (as, for instance, is the case with
ProjectSpace#revert) you might run into problems.
To illustrate, consider the following example:

Suppose clients 1 and 2 both have a project state checked out, where
two elements 'A' and 'B' exists, which reference each other.

Client 2 creates a new element 'C' and creates a new connection between
'A' and 'C'. He then commits.

Client 1, which will reject all incoming conflicting changes, deletes
element 'A' and undoes his changes as if nothing happened. He then
performs an update, which does not cause any conflict, since element 'A'
exists, i.e. after the update, element 'A' references elements 'B' and
'C' and vice versa. And since we didn't flush the command stack, client
1 now is capable of redoing his deletion of element 'A'.

If we re-record the deletion during the redo everything works as
expected: element 'A' is deleted and so are the reference between 'A'
and 'B' and 'A' and 'C'.

But if we use the already recorded delete operation, it can't know about
element 'C', hence it will not delete the reference between 'A' and 'C'
causing an broken connection that has a missing element on one side.

FYI: We had a similar problem during updates where re-applied local
changes didn't have the intended effect, since they didn't considered
any changes on elements that might have been introduced during the
update. We therefore created a rerecording option in release 1.4.1
(org.eclipse.emf.emfstore.client.changeRecordingOptions.rerecordLocalChanges).
The implementation might be worth a look.

Hope this helps,

Edgar


> Edgar,
>
> I have a follow-up question to this old thread.
>
> I understand now that undo/redo can cause inconsistent states when
> conflict detection makes changes to local data.
>
> In my application I've implemented a simple, headless conflict
> resolution strategy --- commit my changes, reject their changes.
> Essentially, last write wins.
>
> With this simple rule applied to all updates to the EMFStore server, is
> there any way undo/redo could cause an inconsistent state of the data?
>
> $cott
>
> On 11/11/2013 4:23 AM, Edgar Mueller wrote:
>> Hi Scott,
>>
>> EMFStore doesn't support undo/redo after commit/update, because you are
>> likely to get inconsistent states on your command stack when trying to
>> perform an undo after incoming changes have been applied. For instance,
>> consider the case where a conflict arises. In case you resolve the
>> conflict by choosing to apply the incoming changes, those changes would
>> not have a represenentation on the command stack, i.e. you can not undo
>> incoming changes. So, let's assume that undo would undo only your most
>> recent local change. But then again, what if the model instance you
>> edited just got deleted by the conflict resolution? A undo isn't
>> possible since the model instance does not exist anymore.
>>
>> I hope this helps to see why we choosed to flush the command stack upon
>> commit/update.
>>
>> Cheers,
>> Edgar
>>
>>> I'd like my application's users to be able to undo and redo changes to
>>> their local copies even after a commit. Is this possible? Can this flush
>>> of the CommandStack be eliminated, and, if so, how?
>>
>>
>


--
Edgar Mueller

Get Professional Eclipse Support: http://eclipsesource.com/munich
Previous Topic:[TEXO] Generate code with Maven
Next Topic:[solved] [EMF Forms] Error using View Model Editor: "Bad type on operand stack"
Goto Forum:
  


Current Time: Thu Jul 02 08:28:33 GMT 2015

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

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