Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMFStore] command stack flushing
| [EMFStore] command stack flushing [message #1179081] |
Sun, 10 November 2013 03:21  |
 Scott Dybiec
Messages: 148
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  |
Edgar Mueller
Messages: 89
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 |
Scott Dybiec
Messages: 148
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 |
Scott Dybiec
Messages: 148
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 |
Maximilian Koegel
Messages: 253
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 |
Edgar Mueller
Messages: 89
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
|
|
|
Goto Forum:
Current Time: Wed Apr 24 22:26:49 GMT 2024
Powered by FUDForum. Page generated in 0.03217 seconds |
] 
Search
Help
Register
Login
Home
