Community
Participate
Working Groups
Currently, when #rollback is called on a CDOTransaction, the CDOObjects that are restored from their DIRTY state to their CLEAN state, do not send EMF Notifications to their eAdapters. This is problematic, for example, if the affected CDOObjects are being displayed in a UI, as any presentation layer depending on Notifications will be unaware of the rollback and therefore continue to display the unrollbacked (i.e. dirty) state of the objects. We propose therefore to send a normal EMF Notification for each change that is made to each of the CDOObjects that are being restored from DIRTY to CLEAN during a rollback, so that, as far as any adapters are concerned, the state change of the object is communicated to them normally. That is, from the point of view of the adapters, there will be no difference between a modification of a CDOObject due to a rollback, and a "normal" modification. If it seems necessary to allow adapters to distinguish between normal changes and rollback changes, then perhaps the Notifications can carry some state to provide this extra info.
SHould it receives one notification per feature ? or one for everything ? Like the changerecorder will behave (one per feature) Because if it not.... should we not just listen on CDOTransaction for rollback ? Simon
Another comments... EMFNotification are create for remote changes... In your case it is not. SO I'm wondering what will be the best design to add that. Should we add another options.. to notify object on rollback ? - Complete (default) (One per features) - Compact (One per object) - None NONE Simon
(In reply to comment #2) For the use cases I was thinking of, the "complete notifications" option makes most sense. But indeed, some types of adapters are probably better served through "compact" notifications, or might not even want rollback notifications at all. So I agree, making this configurable is a good idea.
Rebasing all outstanding enhancements requests to version 4.0
Created attachment 187715 [details] Patch v1 Pascal offered to write a test...
Committed revision 6945
Committed revision 6948
Created attachment 187745 [details] Testcase v1 I added a couple of different test. If I missed an important one please let me know and I can add it :) Also, when writing the tests, I became aware that the rollbacked object stay in PROXY state until accessed again. The notification is not sent until the object is reloaded, so it would be nice to have the option of the objects being reloaded automatically on rollback.
I changed rollbackRevision.get() ro remove() in the LoadTransition. Committed revision 6949
Created attachment 187747 [details] Testcase v2 - ready to be committed Just reformatted.
(In reply to comment #8) > Also, when writing the tests, I became aware that the rollbacked object stay in > PROXY state until accessed again. The notification is not sent until the object > is reloaded, so it would be nice to have the option of the objects being > reloaded automatically on rollback. I wonder if we should better expose rollbackObjects.keySet() in the CDOTransactionFinishedEvent. Maybe we should separate two event types for Committed and RolledBack...
The new tests all seem to fail in LEGACY. Are there any equals checks that do not consider legacy adapters? Investigating...
I think it would be a good idea to emit EMF notfications in case of a transaction rollback. Maybe a new option should be introduced which enables this feature. I'll attach a patch...
Created attachment 187818 [details] Enables EMF notifications on transaction.rollback() I confirm to 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
The CDOLegacyWrapper had to be optimized to work with the new changes. The cdoInternalPostRollback() method now behaves more comparable to the native call. Changes in the LoadTransition are now also availbale in the legacy mode. Committed revision 6955
Created attachment 187823 [details] Testcase v3 - ready to be committed I changed the test case a bit to make it work with legacy. All test a now passing. Testcase v3 - ready to be committed
Created attachment 187850 [details] Enables EMF notifications on transaction.rollback() Performance improvments after discussion with Eike... Now fetching all revisions in one call. I confirm to 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
Committed revision 6959 (Testcase v3)
Committed revision 6964
Committed revision 6980: - trunk/plugins/org.eclipse.emf.cdo
Committed revision 6980
Committed revision 6981: - trunk/plugins/org.eclipse.emf.cdo
Available in R20110608-1407
