Home » Modeling » EMF » A "do it again" ChangeRecorder
| A "do it again" ChangeRecorder [message #514132] |
Fri, 12 February 2010 14:31  |
 Cyril Jaquier
Messages: 80
Registered: July 2009 |
Member |
|
|
Hi all,
Our product has an "After Action Review" feature which records and
time-stamps any changes made to the model. Thus it is possible to replay
the action again later.
We are now moving from "our own model framework/JAXB" to "EMF/CDO".
The EMF Change Model seems to be a good starting point. We could
generate ChangeDescription at regular intervals and serialize them to
disk. Then the playback function would be a matter of loading the
ChangeDescription again and apply them at regular intervals too.
1/ ChangeRecorder records the modifications in the wrong way for us. We
don't need to undo the changes but to "do them again" later. Not a big
trouble, we could write our own ChangeRecorder. However, it seems that
we have a problem with ChangeDescription#objectsToAttach which is a
containment. We can't add the new object to objectsToAttach when we
receive a Notification.ADD (this will remove the object from our model).
Is making ChangeDescription#objectsToAttach a non-containment reference
a solution? What are the consequences?
2/ We also require ChangeDescription#apply not to clear the
ChangeDescription. The "After Action Review" feature allows backward
skips. In such case, we re-initialize our model and would apply all the
needed ChangeDescription again. Am I right in assuming that we will need
to rewrite most of the ChangeDescription, FeatureChange, ListChange, etc
implementations to do this?
3/ Another solution would be to open a CDO transaction, to use the
standard ChangeRecoder, to applyAndReverse the ChangeDescription, to
serialize it and to rollback the transaction. However, because
Notification#getOldValue is always null when using CDO, we guess that
applyAndReverse will either fail or not give back the excepted changes.
4/ Yet another solution would be CDO's audit mode. But this mode does
not allow deletion of old content at the moment. Our product needs to
run 24/24 and the amount of modifications is quite huge so we need to be
able to remove old data at runtime.
Any idea, suggestion, pointers are strongly appreciated as we are a bit
confused at the moment.
Thank you.
Regards,
Cyril Jaquier
|
|
|
| Re: A "do it again" ChangeRecorder [message #514141 is a reply to message #514132] |
Fri, 12 February 2010 15:00  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Cyril,
Comments below.
Cyril Jaquier wrote:
> Hi all,
>
> Our product has an "After Action Review" feature which records and
> time-stamps any changes made to the model. Thus it is possible to
> replay the action again later.
>
> We are now moving from "our own model framework/JAXB" to "EMF/CDO".
Another JAXBotomy...
>
> The EMF Change Model seems to be a good starting point. We could
> generate ChangeDescription at regular intervals and serialize them to
> disk. Then the playback function would be a matter of loading the
> ChangeDescription again and apply them at regular intervals too.
>
> 1/ ChangeRecorder records the modifications in the wrong way for us.
> We don't need to undo the changes but to "do them again" later. Not a
> big trouble, we could write our own ChangeRecorder. However, it seems
> that we have a problem with ChangeDescription#objectsToAttach which is
> a containment. We can't add the new object to objectsToAttach when we
> receive a Notification.ADD (this will remove the object from our
> model). Is making ChangeDescription#objectsToAttach a non-containment
> reference a solution? What are the consequences?
You need to keep in mind some tricky aspects. When you serialize a
change description, it's important to consider how the objects are
referenced. I think it would be extremely hard to make this work trying
to serialize against a state that the model really isn't in. Objects
that need to be added to the model need to be contained by the change
description; they don't live anywhere else. Object that needed to be
removed from the model, are contained by the model and hence they need
to be referenced from the change description. No amount of hacking is
going to get around issues likes this.
>
> 2/ We also require ChangeDescription#apply not to clear the
> ChangeDescription. The "After Action Review" feature allows backward
> skips. In such case, we re-initialize our model and would apply all
> the needed ChangeDescription again. Am I right in assuming that we
> will need to rewrite most of the ChangeDescription, FeatureChange,
> ListChange, etc implementations to do this?
This model was a very hard thing to get right. I doubt you'll be
successful without huge effort.
>
> 3/ Another solution would be to open a CDO transaction, to use the
> standard ChangeRecoder, to applyAndReverse the ChangeDescription, to
> serialize it and to rollback the transaction. However, because
> Notification#getOldValue is always null when using CDO, we guess that
> applyAndReverse will either fail or not give back the excepted changes.
You'll have noticed that if you do use applyAndReverse repeatedly. So
you could do that once, serialize it, and then do it again. The
serialize form could then be deserialized somewhere else, against the
original state of the model, and then of course applyAndReverse could be
used to transform that instance to the same final state...
>
> 4/ Yet another solution would be CDO's audit mode. But this mode does
> not allow deletion of old content at the moment. Our product needs to
> run 24/24 and the amount of modifications is quite huge so we need to
> be able to remove old data at runtime.
>
> Any idea, suggestion, pointers are strongly appreciated as we are a
> bit confused at the moment.
Another possibility is to copy both the instance and the change
description, use applyAndReverse on that, serialize it, and then throw
it all away.
>
> Thank you.
>
> Regards,
> Cyril Jaquier
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: A "do it again" ChangeRecorder [message #514183 is a reply to message #514141] |
Fri, 12 February 2010 17:30 |
Cyril Jaquier
Messages: 80
Registered: July 2009 |
Member |
|
|
Dear Ed,
Thank you very much. My comments are below.
> You need to keep in mind some tricky aspects. When you serialize a
> change description, it's important to consider how the objects are
> referenced. I think it would be extremely hard to make this work trying
> to serialize against a state that the model really isn't in. Objects
> that need to be added to the model need to be contained by the change
> description; they don't live anywhere else. Object that needed to be
> removed from the model, are contained by the model and hence they need
> to be referenced from the change description. No amount of hacking is
> going to get around issues likes this.
Can't the added objects live in the resource? Something like this (with
objectsToAttach as a non-containment reference):
ChangeDescription description= ...
Resource resource= ...
resource.getContents().add(description);
resource.getContents().addAll(description.getObjectsToAttach ());
resource.save(null)
As you have probably notice, I'm quite new to EMF/CDO so the code above
may be completely wrong ;)
> This model was a very hard thing to get right. I doubt you'll be
> successful without huge effort.
Yes that's definitely not the way we want to go because 1/ we have not
enough knowledge of EMF's internals and because 2/ time is an important
factor at the moment.
> Another possibility is to copy both the instance and the change
> description, use applyAndReverse on that, serialize it, and then throw
> it all away.
Maybe another idea. We use "scenes" to store the AAR (After Action
Review) data. A scene has an "initial state" (a snapshot of our model)
and "actions". Actions are timestamped modifications to the model. A
scene represents in average 10 minutes. To play the AAR, we loads the
corresponding scenes, initializes the model with the initial state of
the first scene and then play back the modifications using the
"actions". If the user skips forward (or backward) to T', we
re-initialize the model with the "initial state" of the scene nearest to
T' and play "internally" the "action" up to T'. It's similar to video
with key frames.
Below is a schema representing a scene. "I" is the "initial state" and
"->" represents the "actions".
scene
..------------------------.
I -> | -> | -> | -> | -> |
So now with EMF/CDO, we could have scenes with a "final state" and
"changes". If we now load the "final state" and applyAndReverse all the
ChangeDescription, we will get the initial state of the scene. We can
then apply (using applyAndReverse) the ChangeDescription in the reverse
order to play the changes chronologically. Thanks to CDO's transaction
view, the changes will be only visible to the client after the commit.
Below is a schema representing a EMF scene. "F" is the final state" and
"<-" represents the "changes" (ChangeDescription).
scene
..------------------------.
| <- | <- | <- | <- | <- F
after loading "F" and applying all the changes in the reverse order
we'll get this:
scene
..------------------------.
| -> | -> | -> | -> | -> F
with the model in the same state as "I" in the first schema. The
transition to the next scene will require the same operations.
Now we can use the standard ChangeRecorder and ChangeDescription with
little modifications to record the data.
To play back the scenes again is more tricky but I think it will be a
way easier than hacking the Change Model.
I probably missed some issues here but I think/hope this solution could
work.
It's time for beer now. We'll investigate this further on Monday.
Regards,
Cyril
|
|
|
| Re: A "do it again" ChangeRecorder [message #514190 is a reply to message #514183] |
Fri, 12 February 2010 13:08 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Cyril,
Comments below.
Cyril Jaquier wrote:
> Dear Ed,
>
> Thank you very much. My comments are below.
>
>> You need to keep in mind some tricky aspects. When you serialize a
>> change description, it's important to consider how the objects are
>> referenced. I think it would be extremely hard to make this work
>> trying to serialize against a state that the model really isn't in.
>> Objects that need to be added to the model need to be contained by
>> the change description; they don't live anywhere else. Object that
>> needed to be removed from the model, are contained by the model and
>> hence they need to be referenced from the change description. No
>> amount of hacking is going to get around issues likes this.
>
> Can't the added objects live in the resource? Something like this
> (with objectsToAttach as a non-containment reference):
Yes, but that's not a general solution either because only if a
containment reference is proxy resolving can an object be contained by a
resource and by some container EObject's containment reference.
>
> ChangeDescription description= ...
> Resource resource= ...
> resource.getContents().add(description);
> resource.getContents().addAll(description.getObjectsToAttach ());
> resource.save(null)
>
> As you have probably notice, I'm quite new to EMF/CDO so the code
> above may be completely wrong ;)
Yes and being new, you want to solve one of the more challenging
problems we've had to solve already.
>
>
>> This model was a very hard thing to get right. I doubt you'll be
>> successful without huge effort.
>
> Yes that's definitely not the way we want to go because 1/ we have not
> enough knowledge of EMF's internals and because 2/ time is an
> important factor at the moment.
>
>
>> Another possibility is to copy both the instance and the change
>> description, use applyAndReverse on that, serialize it, and then
>> throw it all away.
>
> Maybe another idea. We use "scenes" to store the AAR (After Action
> Review) data. A scene has an "initial state" (a snapshot of our model)
> and "actions". Actions are timestamped modifications to the model. A
> scene represents in average 10 minutes. To play the AAR, we loads the
> corresponding scenes, initializes the model with the initial state of
> the first scene and then play back the modifications using the
> "actions". If the user skips forward (or backward) to T', we
> re-initialize the model with the "initial state" of the scene nearest
> to T' and play "internally" the "action" up to T'. It's similar to
> video with key frames.
>
> Below is a schema representing a scene. "I" is the "initial state" and
> "->" represents the "actions".
>
> scene
> .------------------------.
> I -> | -> | -> | -> | -> |
>
>
> So now with EMF/CDO, we could have scenes with a "final state" and
> "changes". If we now load the "final state" and applyAndReverse all
> the ChangeDescription, we will get the initial state of the scene. We
> can then apply (using applyAndReverse) the ChangeDescription in the
> reverse order to play the changes chronologically. Thanks to CDO's
> transaction view, the changes will be only visible to the client after
> the commit.
>
> Below is a schema representing a EMF scene. "F" is the final state"
> and "<-" represents the "changes" (ChangeDescription).
>
> scene
> .------------------------.
> | <- | <- | <- | <- | <- F
>
>
> after loading "F" and applying all the changes in the reverse order
> we'll get this:
>
> scene
> .------------------------.
> | -> | -> | -> | -> | -> F
>
>
> with the model in the same state as "I" in the first schema. The
> transition to the next scene will require the same operations.
>
> Now we can use the standard ChangeRecorder and ChangeDescription with
> little modifications to record the data.
Not sure about the little modifications. Best to use them as is.
>
> To play back the scenes again is more tricky but I think it will be a
> way easier than hacking the Change Model.
>
> I probably missed some issues here but I think/hope this solution
> could work.
>
> It's time for beer now. We'll investigate this further on Monday.
>
> Regards,
> Cyril
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 20:21:46 GMT 2024
Powered by FUDForum. Page generated in 0.03931 seconds |
] 
Search
Help
Register
Login
Home
