Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Help with ChangeRecorder / workbench-wide model
Help with ChangeRecorder / workbench-wide model [message #653810] Fri, 11 February 2011 05:25 Go to next message
Neil Bartlett is currently offline Neil Bartlett
Messages: 93
Registered: July 2009
Member
Hi all,

Could somebody tell me whether I can use ChangeRecorder to achieve the
following requirement, or alternatively let me know if there is a better
way.

I have an RCP application that uses a workbench-wide EMF model, operated
upon by multiple views and editors. In the editors I don't want the
user's interim changes to actually mutate the model until Save is
pressed. So I thought about doing the following:

1) Clone the original model object and start a ChangeRecorder on the
clone. Allow modification of the clone in the editor.

2) When save is pressed, replay the changes in the CloneRecorder against
the original model object.

I considered simply using EcoreUtil.replace() to replace the original
model object with the clone upon save, but I want to preserve any
changes that might made in the original object while the clone is being
edited, so long as they do not conflict with changes made in the editor
(in case there is a conflict, the editor version wins).

Is this a practical solution? Or is there something much simpler that I
have missed?

Many thanks,
Neil
Re: Help with ChangeRecorder / workbench-wide model [message #653814 is a reply to message #653810] Fri, 11 February 2011 06:33 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5499
Registered: July 2009
Senior Member
Am 11.02.2011 11:25, schrieb Neil Bartlett:
> Hi all,
>
> Could somebody tell me whether I can use ChangeRecorder to achieve the following requirement, or alternatively let me know if there is a better way.
>
> I have an RCP application that uses a workbench-wide EMF model, operated upon by multiple views and editors. In the editors I don't want the user's interim changes to actually mutate the model until Save is pressed. So I thought about doing the following:
>
> 1) Clone the original model object and start a ChangeRecorder on the clone. Allow modification of the clone in the editor.
>
> 2) When save is pressed, replay the changes in the CloneRecorder against the original model object.
>
> I considered simply using EcoreUtil.replace() to replace the original model object with the clone upon save, but I want to preserve any changes that might made in the original object while the clone is being edited, so long as they do not conflict with changes made in the editor (in case there is a conflict, the editor version wins).
>
> Is this a practical solution?
It should work. Note that in order to replay the ChangeDescription in the original direction you first have to applyAndReverse() it once, ideally on the clone that you're going to throw away thereafter.

> Or is there something much simpler that I have missed?
Yes, CDO :P

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: Help with ChangeRecorder / workbench-wide model [message #653819 is a reply to message #653810] Fri, 11 February 2011 06:56 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5279
Registered: July 2009
Senior Member
Hi,

Like Eike already responded to your question I'd like to present you how
we are making use of EMF inside RCP-Application.

a) By using CDO which is the preferred option because then we don't
have to care about all the change management, ... .

b) By using Teneo/Hibernate and sending out events with change
informations so that we can reload specific parts in other
editors (if possible we keep the users current modifications).
Normally editors only see a very small portion of the Object-Graph.

We are not relying on the change recorder to apply the changes but
issue a refresh on hibernate.

Tom

Am 11.02.11 11:25, schrieb Neil Bartlett:
> Hi all,
>
> Could somebody tell me whether I can use ChangeRecorder to achieve the
> following requirement, or alternatively let me know if there is a better
> way.
>
> I have an RCP application that uses a workbench-wide EMF model, operated
> upon by multiple views and editors. In the editors I don't want the
> user's interim changes to actually mutate the model until Save is
> pressed. So I thought about doing the following:
>
> 1) Clone the original model object and start a ChangeRecorder on the
> clone. Allow modification of the clone in the editor.
>
> 2) When save is pressed, replay the changes in the CloneRecorder against
> the original model object.
>
> I considered simply using EcoreUtil.replace() to replace the original
> model object with the clone upon save, but I want to preserve any
> changes that might made in the original object while the clone is being
> edited, so long as they do not conflict with changes made in the editor
> (in case there is a conflict, the editor version wins).
>
> Is this a practical solution? Or is there something much simpler that I
> have missed?
>
> Many thanks,
> Neil
Re: Help with ChangeRecorder / workbench-wide model [message #653848 is a reply to message #653814] Fri, 11 February 2011 09:10 Go to previous messageGo to next message
Neil Bartlett is currently offline Neil Bartlett
Messages: 93
Registered: July 2009
Member
On 11/02/2011 11:33, Eike Stepper wrote:
> Am 11.02.2011 11:25, schrieb Neil Bartlett:
> It should work. Note that in order to replay the ChangeDescription in
> the original direction you first have to applyAndReverse() it once,
> ideally on the clone that you're going to throw away thereafter.

Thanks, I'm aware that the initial change description is reversed. But
after doing applyAndReverse(), how do I then replay it against the
original object? There doesn't appear to be a way to switch the eObject
or eResource against which the ChangeDescription is applied.


>> Or is there something much simpler that I have missed?
> Yes, CDO :P

I said something simpler!

Seriously... in what way does CDO help with this problem? I've
complained about CDO's documentation before and it hasn't got any
better. It's massively intimidating and there is no simple explanation
of what CDO might do for me.


>
> Cheers
> /Eike

Thanks!
Neil
Re: Help with ChangeRecorder / workbench-wide model [message #653926 is a reply to message #653848] Fri, 11 February 2011 16:54 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5499
Registered: July 2009
Senior Member
Am 11.02.2011 15:10, schrieb Neil Bartlett:
>
>>> Or is there something much simpler that I have missed?
>> Yes, CDO :P
>
> I said something simpler!
>
> Seriously... in what way does CDO help with this problem?
CDO can provide you with multiple transactions on the same model. These transactions give you different EObject instances for the same logical object, while their underlying state is shared as long as a transaction does not modify it. No need to fiddle with a ChangeRecorder.

> I've complained about CDO's documentation before
Yes, on Twitter. Not very nice from you because that's not the official support forum and without a firend's hint I wouldn't have the chance to publicly comment on your complaints.

> and it hasn't got any better.
All the points you explicitely complained about have been fixed immediately. I recognize that we have no CDO book available but as I told you previously, we have a lot of content in the wiki http://wiki.eclipse.org/CDO and some useful information on the homepage http://www.eclipse.org/cdo/

> It's massively intimidating and there is no simple explanation of what CDO might do for me.
The wiki says:

"The CDO (Connected Data Objects) Model Repository is a distributed shared model framework for EMF <http://wiki.eclipse.org/EMF> models and meta models. CDO is also a model runtime environment with a focus on orthogonal aspects like model scalability, transactionality, persistence, distribution, queries and more.
CDO has a 3-tier architecture supporting EMF-based client applications, featuring a central model repository server and leveraging different types of pluggable data storage back-ends like relational databases, object databases and file systems. The default client/server communication protocol is implemented with the Net4j <http://wiki.eclipse.org/Net4j> Signalling Platform."

I'm very open to criticism in the form of constructive suggestions.

Cheers
/Eike
Re: Help with ChangeRecorder / workbench-wide model [message #653940 is a reply to message #653926] Fri, 11 February 2011 19:08 Go to previous messageGo to next message
Neil Bartlett is currently offline Neil Bartlett
Messages: 93
Registered: July 2009
Member
On 11/02/2011 21:54, Eike Stepper wrote:
> Am 11.02.2011 15:10, schrieb Neil Bartlett:
>>
>>>> Or is there something much simpler that I have missed?
>>> Yes, CDO :P
>>
>> I said something simpler!
>>
>> Seriously... in what way does CDO help with this problem?
> CDO can provide you with multiple transactions on the same model. These
> transactions give you different EObject instances for the same logical
> object, while their underlying state is shared as long as a transaction
> does not modify it. No need to fiddle with a ChangeRecorder.

I see. This sounds similar to EMF Transactions... is it related?

>> I've complained about CDO's documentation before
> Yes, on Twitter. Not very nice from you because that's not the official
> support forum and without a firend's hint I wouldn't have the chance to
> publicly comment on your complaints.

Well I apologise for that but at the time I couldn't even find your
official support forum because your web presence was mostly full of
"coming soon" and 404 links. I agree that this has got somewhat better now.

>
>> and it hasn't got any better.
> All the points you explicitely complained about have been fixed
> immediately. I recognize that we have no CDO book available but as I
> told you previously, we have a lot of content in the wiki
> http://wiki.eclipse.org/CDO and some useful information on the homepage
> http://www.eclipse.org/cdo/

There is more documentation new on the wiki now but nothing that appears
to be an introduction to CDO. It covers some very specific details but
where to get started?

I must admit that this was my impression of EMF itself for a long time.
It also does a very, very poor job of communicating just what it is for
and why it adds value. Somehow I think I have now absorbed enough
ambient information about EMF to understand it -- CDO is still a mystery.

>
>> It's massively intimidating and there is no simple explanation of what
>> CDO might do for me.
> The wiki says:
>
> "The CDO (Connected Data Objects) Model Repository is a distributed
> shared model framework for EMF <http://wiki.eclipse.org/EMF> models and
> meta models. CDO is also a model runtime environment with a focus on
> orthogonal aspects like model scalability, transactionality,
> persistence, distribution, queries and more.
>
> CDO has a 3-tier architecture supporting EMF-based client applications,
> featuring a central model repository server and leveraging different
> types of pluggable data storage back-ends like relational databases,
> object databases and file systems. The default client/server
> communication protocol is implemented with the Net4j
> <http://wiki.eclipse.org/Net4j> Signalling Platform."

> I'm very open to criticism in the form of constructive suggestions.

Look, please don't get defensive, I do *want* to understand CDO and even
help you to make it understandable to others. But the first paragraph of
the "simple explanation" is just incomprehensible buzzword-bingo. Am I
simply stupid?? It reminds me of those horrible "Mission Statements"
that big corporations write... eg. "we will harness synergies to develop
360-degree growth paradigms yada yada".

The second paragraph is not so bad, but it's about implementation
details. I don't care how many tiers you have or what your communication
protocol is until I know that I want to use CDO at all.

The impression I get from CDO right now is that it's a big framework
that tries to do everything and take over my entire application, both
client-side and server-side; it will take me months to learn and
probably won't do exactly what I want so I will have to fight it
constantly just to deliver features that I could have easily implemented
if only I'd built by own stuff.

If that's an inaccurate impression, you need to tell people why CDO is
different from all the other do-everything frameworks! I've been burned
in the past by over-ambitious frameworks, and so have many other developers.

If you can't explain these things adequately then you need help from
somebody who can. I hope that's constructive enough for you, it's the
best I can do.

Cheers,
Neil


>
> Cheers
> /Eike
>
Re: Help with ChangeRecorder / workbench-wide model [message #653953 is a reply to message #653848] Fri, 11 February 2011 21:17 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Neil,

Comments below.

Neil Bartlett wrote:
> On 11/02/2011 11:33, Eike Stepper wrote:
>> Am 11.02.2011 11:25, schrieb Neil Bartlett:
>> It should work. Note that in order to replay the ChangeDescription in
>> the original direction you first have to applyAndReverse() it once,
>> ideally on the clone that you're going to throw away thereafter.
>
> Thanks, I'm aware that the initial change description is reversed. But
> after doing applyAndReverse(), how do I then replay it against the
> original object?
Generally I'd expect you to serialize the result in a resource and
transport that to somewhere where the original objects are known. The
deserialized result will contain proxies, initially and those will
resolve to the original objects. So a quick and dirty way to simulate
that is to serialize to a byte stream and load from that...
> There doesn't appear to be a way to switch the eObject or eResource
> against which the ChangeDescription is applied.
>
>
>>> Or is there something much simpler that I have missed?
>> Yes, CDO :P
>
> I said something simpler!
>
> Seriously... in what way does CDO help with this problem? I've
> complained about CDO's documentation before and it hasn't got any better.
I'm sure you've noticed that complaints never make anything better.
Making things better involves significant time and effort; massive
unrewarding effort actually. And when you do that, people will still
complain that it's hard to find the one thing they want, that's too
detailed and not detailed enough. There's just no pleasing everyone.
And of course, as developers, we generally like to invest our time and
effort in the functionality of the software.
> It's massively intimidating and there is no simple explanation of what
> CDO might do for me.
>
>
>>
>> Cheers
>> /Eike
>
> Thanks!
> Neil
Previous Topic:Custom serialization of Map$Entry
Next Topic:Combining EMF switch classes
Goto Forum:
  


Current Time: Thu Aug 21 10:12:28 EDT 2014

Powered by FUDForum. Page generated in 0.06007 seconds