Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Compare] is it possible for the diff to hold the old values?
[Compare] is it possible for the diff to hold the old values? [message #123844] Thu, 29 May 2008 18:48 Go to next message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
Hi all,

I guess I slightly mis-understood what compare would do for me. I'm
wondering if I'm just not using it correctly or there's some parameter
that I could set.

Right now I'm comparing two an old version of an object and a new
version of an object. I'd like to get the diff so that I can build an
object log.

After my compare I get this XML

<diff:ModelInputSnapshot xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
<diff left="original.xml" right="altered.xml">
<ownedElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute
href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
<leftElement href="original.xml#/"/>
<rightElement href="altered.xml#/"/>
</subDiffElements>
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute href="http://model.lab.vsp.com#//Lab/labType"/>
<leftElement href="original.xml#/"/>
<rightElement href="altered.xml#/"/>
</subDiffElements>
<subDiffElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute
href="http://model.lab.vsp.com#//Affiliation/affiliationType"/>
<leftElement href="original.xml#//@affiliationList.0"/>
<rightElement href="altered.xml#//@affiliationList.0"/>
</subDiffElements>
<leftParent href="original.xml#//@affiliationList.0"/>
</subDiffElements>
<subDiffElements xsi:type="diff:AddModelElement">
<leftParent href="original.xml#/"/>
<rightElement href="altered.xml#//@contactList.2"/>
</subDiffElements>
<leftParent href="original.xml#/"/>
</subDiffElements>
</ownedElements>
</diff>
</diff:ModelInputSnapshot>

Let's focus on the updated attribute:

<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute
href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
<leftElement href="original.xml#/"/>
<rightElement href="altered.xml#/"/>
</subDiffElements>

I had thought that the diff would display the old VALUE of the
attribute, not just the resource that it's located in. The old resource
will be getting deleted momentarily and replaced with the new one so I
wont have it to refer back to.

This is still somewhat helpful because I can see what was changed, but I
don't have any idea what it used to be. I'd love to see something more
like this:

<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute
href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
<leftElement href="original.xml#/" value="AAA"/>
<rightElement href="altered.xml#/" value="BBB"/>
</subDiffElements>


Certainly I can see how this request is tricky. In cases where a whole
sub-object was deleted what would be stored? I'm not sure.

Is this something that is even remotely possible, or is this kind of a
diff outside the current scope of the project?

Thanks!

Jason Henriksen
Re: [Compare] is it possible for the diff to hold the old values? [message #124014 is a reply to message #123844] Fri, 30 May 2008 07:28 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi jason,

The XML file EMF compare is providing you is in fact an EMF model, and as
such you can load it using the EMF standards code. That said, the diff
model is referencing both the elements of your version 1 and version2
models, which mean, if I take your example, that once loaded using EMF you
can get to your "UpdateAttribute" instance, and then

UpdateAttribute myUpdateDiff =.... // you can browse the diff model and
find back this element using the EMF eAllContents() for instance.

EStructuralFeature updatedFeature = myUpdateDiff.getAttribute();
Object oldValue= myUpdateDiff.getLeftElement().eGet(updatedFeature);
Object newValue= myUpdateDiff.getRightElement().eGet(updatedFeature);

I strongly advise you to use the model loaded thanks to EMF instead of
working on the XML level as the references resolving can be quite tricky is
you do it "by hand".

You'll find an example of a customized diff export in the modeling CVS
(dev.eclipse.org cvsroot=/cvsroot/modeling) called
org.eclipse.emf.compare.example.export.library and the corresponding
documentation in the Eclipse help "Adding new actions to the export menu".

For the next (Ganymede +1) release we'll work on a "self contained diff" you
could apply on other models - which makes it a kind of "patch"
or "changeset", but then it's more about re-applying/undoing changes than
about leveraging the diff.

Cheers,

Cédric

jason henriksen wrote:

> Hi all,
>
> I guess I slightly mis-understood what compare would do for me. I'm
> wondering if I'm just not using it correctly or there's some parameter
> that I could set.
>
> Right now I'm comparing two an old version of an object and a new
> version of an object. I'd like to get the diff so that I can build an
> object log.
>
> After my compare I get this XML
>
> <diff:ModelInputSnapshot xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
> <diff left="original.xml" right="altered.xml">
> <ownedElements xsi:type="diff:DiffGroup">
> <subDiffElements xsi:type="diff:DiffGroup">
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
> <leftElement href="original.xml#/"/>
> <rightElement href="altered.xml#/"/>
> </subDiffElements>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute href="http://model.lab.vsp.com#//Lab/labType"/>
> <leftElement href="original.xml#/"/>
> <rightElement href="altered.xml#/"/>
> </subDiffElements>
> <subDiffElements xsi:type="diff:DiffGroup">
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Affiliation/affiliationType"/>
> <leftElement href="original.xml#//@affiliationList.0"/>
> <rightElement href="altered.xml#//@affiliationList.0"/>
> </subDiffElements>
> <leftParent href="original.xml#//@affiliationList.0"/>
> </subDiffElements>
> <subDiffElements xsi:type="diff:AddModelElement">
> <leftParent href="original.xml#/"/>
> <rightElement href="altered.xml#//@contactList.2"/>
> </subDiffElements>
> <leftParent href="original.xml#/"/>
> </subDiffElements>
> </ownedElements>
> </diff>
> </diff:ModelInputSnapshot>
>
> Let's focus on the updated attribute:
>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
> <leftElement href="original.xml#/"/>
> <rightElement href="altered.xml#/"/>
> </subDiffElements>
>
> I had thought that the diff would display the old VALUE of the
> attribute, not just the resource that it's located in. The old resource
> will be getting deleted momentarily and replaced with the new one so I
> wont have it to refer back to.
>
> This is still somewhat helpful because I can see what was changed, but I
> don't have any idea what it used to be. I'd love to see something more
> like this:
>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
> <leftElement href="original.xml#/" value="AAA"/>
> <rightElement href="altered.xml#/" value="BBB"/>
> </subDiffElements>
>
>
> Certainly I can see how this request is tricky. In cases where a whole
> sub-object was deleted what would be stored? I'm not sure.
>
> Is this something that is even remotely possible, or is this kind of a
> diff outside the current scope of the project?
>
> Thanks!
>
> Jason Henriksen


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: [Compare] is it possible for the diff to hold the old values? [message #124066 is a reply to message #124014] Fri, 30 May 2008 10:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------050101070600040804040806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Cédric,

I guess it would be possible to transform a diff model instance into a
ChangeDescription instance... I.e., it would be possible to create a
ChangeDescription that describes how to turn the left instances into the
right instance as well as one to turn the right instance into the left
instance. I'm not sure what it would be used for, but it struck me as
potentially interesting since a change description can be applied to
actually make the changes...


Cédric Brun wrote:
> Hi jason,
>
> The XML file EMF compare is providing you is in fact an EMF model, and as
> such you can load it using the EMF standards code. That said, the diff
> model is referencing both the elements of your version 1 and version2
> models, which mean, if I take your example, that once loaded using EMF you
> can get to your "UpdateAttribute" instance, and then
>
> UpdateAttribute myUpdateDiff =.... // you can browse the diff model and
> find back this element using the EMF eAllContents() for instance.
>
> EStructuralFeature updatedFeature = myUpdateDiff.getAttribute();
> Object oldValue= myUpdateDiff.getLeftElement().eGet(updatedFeature);
> Object newValue= myUpdateDiff.getRightElement().eGet(updatedFeature);
>
> I strongly advise you to use the model loaded thanks to EMF instead of
> working on the XML level as the references resolving can be quite tricky is
> you do it "by hand".
>
> You'll find an example of a customized diff export in the modeling CVS
> (dev.eclipse.org cvsroot=/cvsroot/modeling) called
> org.eclipse.emf.compare.example.export.library and the corresponding
> documentation in the Eclipse help "Adding new actions to the export menu".
>
> For the next (Ganymede +1) release we'll work on a "self contained diff" you
> could apply on other models - which makes it a kind of "patch"
> or "changeset", but then it's more about re-applying/undoing changes than
> about leveraging the diff.
>
> Cheers,
>
> Cédric
>
> jason henriksen wrote:
>
>
>> Hi all,
>>
>> I guess I slightly mis-understood what compare would do for me. I'm
>> wondering if I'm just not using it correctly or there's some parameter
>> that I could set.
>>
>> Right now I'm comparing two an old version of an object and a new
>> version of an object. I'd like to get the diff so that I can build an
>> object log.
>>
>> After my compare I get this XML
>>
>> <diff:ModelInputSnapshot xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
>> <diff left="original.xml" right="altered.xml">
>> <ownedElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
>> <leftElement href="original.xml#/"/>
>> <rightElement href="altered.xml#/"/>
>> </subDiffElements>
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute href="http://model.lab.vsp.com#//Lab/labType"/>
>> <leftElement href="original.xml#/"/>
>> <rightElement href="altered.xml#/"/>
>> </subDiffElements>
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Affiliation/affiliationType"/>
>> <leftElement href="original.xml#//@affiliationList.0"/>
>> <rightElement href="altered.xml#//@affiliationList.0"/>
>> </subDiffElements>
>> <leftParent href="original.xml#//@affiliationList.0"/>
>> </subDiffElements>
>> <subDiffElements xsi:type="diff:AddModelElement">
>> <leftParent href="original.xml#/"/>
>> <rightElement href="altered.xml#//@contactList.2"/>
>> </subDiffElements>
>> <leftParent href="original.xml#/"/>
>> </subDiffElements>
>> </ownedElements>
>> </diff>
>> </diff:ModelInputSnapshot>
>>
>> Let's focus on the updated attribute:
>>
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
>> <leftElement href="original.xml#/"/>
>> <rightElement href="altered.xml#/"/>
>> </subDiffElements>
>>
>> I had thought that the diff would display the old VALUE of the
>> attribute, not just the resource that it's located in. The old resource
>> will be getting deleted momentarily and replaced with the new one so I
>> wont have it to refer back to.
>>
>> This is still somewhat helpful because I can see what was changed, but I
>> don't have any idea what it used to be. I'd love to see something more
>> like this:
>>
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
>> <leftElement href="original.xml#/" value="AAA"/>
>> <rightElement href="altered.xml#/" value="BBB"/>
>> </subDiffElements>
>>
>>
>> Certainly I can see how this request is tricky. In cases where a whole
>> sub-object was deleted what would be stored? I'm not sure.
>>
>> Is this something that is even remotely possible, or is this kind of a
>> diff outside the current scope of the project?
>>
>> Thanks!
>>
>> Jason Henriksen
>>
>
>


--------------050101070600040804040806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cédric,<br>
<br>
I guess it would be possible to transform a diff model instance into a
ChangeDescription instance...  I.e., it would be possible to create a
ChangeDescription that describes how to turn the left instances into
the right instance as well as one to turn the right instance into the
left instance.  I'm not sure what it would be used for, but it struck
me as potentially interesting since a change description can be applied
to actually make the changes...<br>
<br>
<br>
Cédric Brun wrote:
<blockquote cite="mid:g1o9ou$eo1$1@build.eclipse.org" type="cite">
<pre wrap="">Hi jason,

The XML file EMF compare is providing you is in fact an EMF model, and as
such you can load it using the EMF standards code. That said, the diff
model is referencing both the elements of your version 1 and version2
models, which mean, if I take your example, that once loaded using EMF you
can get to your "UpdateAttribute" instance, and then

UpdateAttribute myUpdateDiff =.... // you can browse the diff model and
find back this element using the EMF eAllContents() for instance.

EStructuralFeature updatedFeature = myUpdateDiff.getAttribute();
Object oldValue= myUpdateDiff.getLeftElement().eGet(updatedFeature);
Object newValue= myUpdateDiff.getRightElement().eGet(updatedFeature);

I strongly advise you to use the model loaded thanks to EMF instead of
working on the XML level as the references resolving can be quite tricky is
you do it "by hand".

You'll find an example of a customized diff export in the modeling CVS
(dev.eclipse.org cvsroot=/cvsroot/modeling) called
org.eclipse.emf.compare.example.export.library and the corresponding
documentation in the Eclipse help "Adding new actions to the export menu".

For the next (Ganymede +1) release we'll work on a "self contained diff" you
could apply on other models - which makes it a kind of "patch"
or "changeset", but then it's more about re-applying/undoing changes than
about leveraging the diff.

Cheers,

Cédric

jason henriksen wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hi all,

I guess I slightly mis-understood what compare would do for me. I'm
wondering if I'm just not using it correctly or there's some parameter
that I could set.

Right now I'm comparing two an old version of an object and a new
version of an object. I'd like to get the diff so that I can build an
object log.

After my compare I get this XML

&lt;diff:ModelInputSnapshot xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xmlns:diff=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/compare/diff/1.1">"http://www.eclipse.org/emf/compare/diff/1.1"</a>&gt;
&lt;diff left="original.xml" right="altered.xml"&gt;
&lt;ownedElements xsi:type="diff:DiffGroup"&gt;
&lt;subDiffElements xsi:type="diff:DiffGroup"&gt;
&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labHeadquarterId">"http://model.lab.vsp.com#//Lab/labHeadquarterId"</a>/&gt;
&lt;leftElement href="original.xml#/"/&gt;
&lt;rightElement href="altered.xml#/"/&gt;
&lt;/subDiffElements&gt;
&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labType">"http://model.lab.vsp.com#//Lab/labType"</a>/&gt;
&lt;leftElement href="original.xml#/"/&gt;
&lt;rightElement href="altered.xml#/"/&gt;
&lt;/subDiffElements&gt;
&lt;subDiffElements xsi:type="diff:DiffGroup"&gt;
&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Affiliation/affiliationType">"http://model.lab.vsp.com#//Affiliation/affiliationType"</a>/&gt;
&lt;leftElement href=<a class="moz-txt-link-rfc2396E" href="mailto:original.xml#//@affiliationList.0">"original.xml#//@affiliationList.0 "</a>/&gt;
&lt;rightElement href=<a class="moz-txt-link-rfc2396E" href="mailto:altered.xml#//@affiliationList.0">"altered.xml#//@affiliationList.0 "</a>/&gt;
&lt;/subDiffElements&gt;
&lt;leftParent href=<a class="moz-txt-link-rfc2396E" href="mailto:original.xml#//@affiliationList.0">"original.xml#//@affiliationList.0 "</a>/&gt;
&lt;/subDiffElements&gt;
&lt;subDiffElements xsi:type="diff:AddModelElement"&gt;
&lt;leftParent href="original.xml#/"/&gt;
&lt;rightElement href=<a class="moz-txt-link-rfc2396E" href="mailto:altered.xml#//@contactList.2">"altered.xml#//@contactList.2 "</a>/&gt;
&lt;/subDiffElements&gt;
&lt;leftParent href="original.xml#/"/&gt;
&lt;/subDiffElements&gt;
&lt;/ownedElements&gt;
&lt;/diff&gt;
&lt;/diff:ModelInputSnapshot&gt;

Let's focus on the updated attribute:

&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labHeadquarterId">"http://model.lab.vsp.com#//Lab/labHeadquarterId"</a>/&gt;
&lt;leftElement href="original.xml#/"/&gt;
&lt;rightElement href="altered.xml#/"/&gt;
&lt;/subDiffElements&gt;

I had thought that the diff would display the old VALUE of the
attribute, not just the resource that it's located in. The old resource
will be getting deleted momentarily and replaced with the new one so I
wont have it to refer back to.

This is still somewhat helpful because I can see what was changed, but I
don't have any idea what it used to be. I'd love to see something more
like this:

&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labHeadquarterId">"http://model.lab.vsp.com#//Lab/labHeadquarterId"</a>/&gt;
&lt;leftElement href="original.xml#/" value="AAA"/&gt;
&lt;rightElement href="altered.xml#/" value="BBB"/&gt;
&lt;/subDiffElements&gt;


Certainly I can see how this request is tricky. In cases where a whole
sub-object was deleted what would be stored? I'm not sure.

Is this something that is even remotely possible, or is this kind of a
diff outside the current scope of the project?

Thanks!

Jason Henriksen
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>

--------------050101070600040804040806--
Re: [Compare] is it possible for the diff to hold the old values? [message #124787 is a reply to message #124014] Mon, 02 June 2008 11:37 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: moritz.eysholdt.de

Hi Cédric,

> For the next (Ganymede +1) release we'll work on a "self contained diff" you
> could apply on other models - which makes it a kind of "patch"
> or "changeset", but then it's more about re-applying/undoing changes than
> about leveraging the diff.

that sounds useful for me, too. Is there already a bug for it where I
can add myself to the CC-list?

regards,
Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #124813 is a reply to message #124066] Mon, 02 June 2008 12:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: moritz.eysholdt.de

Hi Ed, hi Cédric,

> I guess it would be possible to transform a diff model instance into a
> ChangeDescription instance... I.e., it would be possible to create a
> ChangeDescription that describes how to turn the left instances into the
> right instance as well as one to turn the right instance into the left
> instance. I'm not sure what it would be used for, but it struck me as
> potentially interesting since a change description can be applied to
> actually make the changes...

I've just run into a situation where I needed what you described. I'm
about to implement some refactorings for Ecore and my current approach
looks like this:

I'm creating a ChangeDescription model by hand (instead of recording it)
within the RefactoringProcessor. To execute the refactoring I only need
to apply the ChangeDescription.

To have a EMF Compare-based perview within the refactoring wizard, I
generate the needed MatchModel like this:

public static MatchModel createMatchModel(EObject left,
ChangeDescription change) {

change.applyAndReverse();

EObject right = EcoreUtil.copy(left);
URI leftUri = left.eResource().getURI();
URI rightUri = URI.createURI(leftUri + "-tmp."
+ leftUri.fileExtension());
ModelUtils.attachResource(rightUri, right);

change.applyAndReverse();

try {
return MatchService.doContentMatch(left, right, null);
} catch (InterruptedException e) {
e.printStackTrace();
return null;
}
}

After applying the change it copies the model and undoes the change
again. This works for a prototype, but it has some disatvantages:

- The actual model is beeing changed just to generate the preview. It
shouldn't be necessary to touch the model for that.
- I haven't looked into the complexity of the match-model yet, but I've
got the feeling that it might be more efficient to derive it derectly
from the ChangeDescription instead of doing all the comparison again.
- If I create a change by hand, I 'know' what is a 'move' and I don't
need an algorithm to make guesses about it...


suggestions?

regards,
Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #124825 is a reply to message #124813] Mon, 02 June 2008 10:31 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Moritz,

Comments below.

Moritz Eysholdt wrote:
> Hi Ed, hi Cédric,
>
>> I guess it would be possible to transform a diff model instance into
>> a ChangeDescription instance... I.e., it would be possible to create
>> a ChangeDescription that describes how to turn the left instances
>> into the right instance as well as one to turn the right instance
>> into the left instance. I'm not sure what it would be used for, but
>> it struck me as potentially interesting since a change description
>> can be applied to actually make the changes...
>
> I've just run into a situation where I needed what you described. I'm
> about to implement some refactorings for Ecore and my current approach
> looks like this:
>
> I'm creating a ChangeDescription model by hand (instead of recording
> it) within the RefactoringProcessor. To execute the refactoring I only
> need to apply the ChangeDescription.
>
> To have a EMF Compare-based perview within the refactoring wizard, I
> generate the needed MatchModel like this:
>
> public static MatchModel createMatchModel(EObject left,
> ChangeDescription change) {
>
> change.applyAndReverse();
>
> EObject right = EcoreUtil.copy(left);
> URI leftUri = left.eResource().getURI();
> URI rightUri = URI.createURI(leftUri + "-tmp."
> + leftUri.fileExtension());
> ModelUtils.attachResource(rightUri, right);
>
> change.applyAndReverse();
>
> try {
> return MatchService.doContentMatch(left, right, null);
> } catch (InterruptedException e) {
> e.printStackTrace();
> return null;
> }
> }
>
> After applying the change it copies the model and undoes the change
> again. This works for a prototype, but it has some disatvantages:
>
> - The actual model is beeing changed just to generate the preview. It
> shouldn't be necessary to touch the model for that.
What if you did an EcoreUtil.copyAll on the change description and the
final version and used applyAndReverse on that to get the original?
> - I haven't looked into the complexity of the match-model yet, but
> I've got the feeling that it might be more efficient to derive it
> derectly from the ChangeDescription instead of doing all the
> comparison again.
I can imagine that's true. So you'd really like something that did
ChangeDescription -> MatchModel. But of course the ChangeDescription
model relies on there being only one instance model's changes being
described while the MatchModel relies on there being two different
instances. Certainly it's easy to use a Copier to end up with two
corresponding identical instances and from there I imagine it ought to
be possible to directly convert between a ChangeDescription and a
MatchModel...
> - If I create a change by hand, I 'know' what is a 'move' and I don't
> need an algorithm to make guesses about it...
One of the hard problems in comparison is establishing the mapping
between the two instances so given that the underlying Copier uses by
EcoreUtil.copy/copyAll knows that correspondence exactly, at least that
information ought to be reused.
>
>
> suggestions?
It sounds like there are some interesting utilities that could be
explored...
>
> regards,
> Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #124837 is a reply to message #124787] Mon, 02 June 2008 10:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Cédric,

I guess that would make it work pretty much exactly like a change
description. Perhaps two way mapping between ChangeDescription <->
MatchModel would be quite an interesting problem to solve. With the
release over soon, maybe I'll have some time to help explore that...


Moritz Eysholdt wrote:
> Hi Cédric,
>
>> For the next (Ganymede +1) release we'll work on a "self contained
>> diff" you
>> could apply on other models - which makes it a kind of "patch"
>> or "changeset", but then it's more about re-applying/undoing changes
>> than
>> about leveraging the diff.
>
> that sounds useful for me, too. Is there already a bug for it where I
> can add myself to the CC-list?
>
> regards,
> Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #124913 is a reply to message #124837] Mon, 02 June 2008 12:44 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi Ed

You're right when you says the changemodel could be considered for these
changesets, and we would like to provide conversion utility for
changemodel<->diffmodel or changemodel<->matchmodel (once models are copied
and the copier is used to produce the matchmodel).

Moreover the "self contained" changeset model, we want to be able to apply
it on a model who have changed over time, a bit like the "fuzzy" search
mode of a textual patch. Then we'll probably ends up with some kind of
container keeping data to find the new root to apply on + the given
changeset.

That's indeed interesting areas to explore :)

I'll trigger a bug to track all the evolution about this subject.

Cédric


Ed Merks wrote:

> Cédric,
>
> I guess that would make it work pretty much exactly like a change
> description. Perhaps two way mapping between ChangeDescription <->
> MatchModel would be quite an interesting problem to solve. With the
> release over soon, maybe I'll have some time to help explore that...
>
>
> Moritz Eysholdt wrote:
>> Hi Cédric,
>>
>>> For the next (Ganymede +1) release we'll work on a "self contained
>>> diff" you
>>> could apply on other models - which makes it a kind of "patch"
>>> or "changeset", but then it's more about re-applying/undoing changes
>>> than
>>> about leveraging the diff.
>>
>> that sounds useful for me, too. Is there already a bug for it where I
>> can add myself to the CC-list?
>>
>> regards,
>> Moritz


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: [Compare] is it possible for the diff to hold the old values? [message #124948 is a reply to message #124825] Mon, 02 June 2008 17:13 Go to previous message
Eclipse UserFriend
Originally posted by: moritz.eysholdt.de

Hi Ed,

thanks for your quick answer.

>> - The actual model is beeing changed just to generate the preview. It
>> shouldn't be necessary to touch the model for that.
> What if you did an EcoreUtil.copyAll on the change description and the
> final version and used applyAndReverse on that to get the original?

thanks for the hint, now

public static EObject copyAndApply(EObject obj, ChangeDescription change) {
EcoreUtil.Copier cop = new Copier();
EObject r = cop.copy(obj);
ChangeDescription c = (ChangeDescription) cop.copy(change);
cop.copyReferences();
c.apply();
return r;
}

public static MatchModel createMatchModel2(EObject left,
ChangeDescription change) {

EObject right = copyAndApply(left, change);

URI leftUri = left.eResource().getURI();
URI rightUri = URI.createURI(leftUri + "-tmp."
+ leftUri.fileExtension());
ModelUtils.attachResource(rightUri, right);

try {
return MatchService.doContentMatch(left, right, null);
} catch (InterruptedException e) {
e.printStackTrace();
return null;
}
}

works for me.

regards,
Moritz


>> - I haven't looked into the complexity of the match-model yet, but
>> I've got the feeling that it might be more efficient to derive it
>> derectly from the ChangeDescription instead of doing all the
>> comparison again.
> I can imagine that's true. So you'd really like something that did
> ChangeDescription -> MatchModel. But of course the ChangeDescription
> model relies on there being only one instance model's changes being
> described while the MatchModel relies on there being two different
> instances. Certainly it's easy to use a Copier to end up with two
> corresponding identical instances and from there I imagine it ought to
> be possible to directly convert between a ChangeDescription and a
> MatchModel...
>> - If I create a change by hand, I 'know' what is a 'move' and I don't
>> need an algorithm to make guesses about it...
> One of the hard problems in comparison is establishing the mapping
> between the two instances so given that the underlying Copier uses by
> EcoreUtil.copy/copyAll knows that correspondence exactly, at least that
> information ought to be reused.
>>
>>
>> suggestions?
> It sounds like there are some interesting utilities that could be
> explored...
>>
>> regards,
>> Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #619093 is a reply to message #123844] Fri, 30 May 2008 07:28 Go to previous message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi jason,

The XML file EMF compare is providing you is in fact an EMF model, and as
such you can load it using the EMF standards code. That said, the diff
model is referencing both the elements of your version 1 and version2
models, which mean, if I take your example, that once loaded using EMF you
can get to your "UpdateAttribute" instance, and then

UpdateAttribute myUpdateDiff =.... // you can browse the diff model and
find back this element using the EMF eAllContents() for instance.

EStructuralFeature updatedFeature = myUpdateDiff.getAttribute();
Object oldValue= myUpdateDiff.getLeftElement().eGet(updatedFeature);
Object newValue= myUpdateDiff.getRightElement().eGet(updatedFeature);

I strongly advise you to use the model loaded thanks to EMF instead of
working on the XML level as the references resolving can be quite tricky is
you do it "by hand".

You'll find an example of a customized diff export in the modeling CVS
(dev.eclipse.org cvsroot=/cvsroot/modeling) called
org.eclipse.emf.compare.example.export.library and the corresponding
documentation in the Eclipse help "Adding new actions to the export menu".

For the next (Ganymede +1) release we'll work on a "self contained diff" you
could apply on other models - which makes it a kind of "patch"
or "changeset", but then it's more about re-applying/undoing changes than
about leveraging the diff.

Cheers,

Cédric

jason henriksen wrote:

> Hi all,
>
> I guess I slightly mis-understood what compare would do for me. I'm
> wondering if I'm just not using it correctly or there's some parameter
> that I could set.
>
> Right now I'm comparing two an old version of an object and a new
> version of an object. I'd like to get the diff so that I can build an
> object log.
>
> After my compare I get this XML
>
> <diff:ModelInputSnapshot xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
> <diff left="original.xml" right="altered.xml">
> <ownedElements xsi:type="diff:DiffGroup">
> <subDiffElements xsi:type="diff:DiffGroup">
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
> <leftElement href="original.xml#/"/>
> <rightElement href="altered.xml#/"/>
> </subDiffElements>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute href="http://model.lab.vsp.com#//Lab/labType"/>
> <leftElement href="original.xml#/"/>
> <rightElement href="altered.xml#/"/>
> </subDiffElements>
> <subDiffElements xsi:type="diff:DiffGroup">
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Affiliation/affiliationType"/>
> <leftElement href="original.xml#//@affiliationList.0"/>
> <rightElement href="altered.xml#//@affiliationList.0"/>
> </subDiffElements>
> <leftParent href="original.xml#//@affiliationList.0"/>
> </subDiffElements>
> <subDiffElements xsi:type="diff:AddModelElement">
> <leftParent href="original.xml#/"/>
> <rightElement href="altered.xml#//@contactList.2"/>
> </subDiffElements>
> <leftParent href="original.xml#/"/>
> </subDiffElements>
> </ownedElements>
> </diff>
> </diff:ModelInputSnapshot>
>
> Let's focus on the updated attribute:
>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
> <leftElement href="original.xml#/"/>
> <rightElement href="altered.xml#/"/>
> </subDiffElements>
>
> I had thought that the diff would display the old VALUE of the
> attribute, not just the resource that it's located in. The old resource
> will be getting deleted momentarily and replaced with the new one so I
> wont have it to refer back to.
>
> This is still somewhat helpful because I can see what was changed, but I
> don't have any idea what it used to be. I'd love to see something more
> like this:
>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
> <leftElement href="original.xml#/" value="AAA"/>
> <rightElement href="altered.xml#/" value="BBB"/>
> </subDiffElements>
>
>
> Certainly I can see how this request is tricky. In cases where a whole
> sub-object was deleted what would be stored? I'm not sure.
>
> Is this something that is even remotely possible, or is this kind of a
> diff outside the current scope of the project?
>
> Thanks!
>
> Jason Henriksen


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: [Compare] is it possible for the diff to hold the old values? [message #619097 is a reply to message #124014] Fri, 30 May 2008 10:55 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31009
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050101070600040804040806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Cédric,

I guess it would be possible to transform a diff model instance into a
ChangeDescription instance... I.e., it would be possible to create a
ChangeDescription that describes how to turn the left instances into the
right instance as well as one to turn the right instance into the left
instance. I'm not sure what it would be used for, but it struck me as
potentially interesting since a change description can be applied to
actually make the changes...


Cédric Brun wrote:
> Hi jason,
>
> The XML file EMF compare is providing you is in fact an EMF model, and as
> such you can load it using the EMF standards code. That said, the diff
> model is referencing both the elements of your version 1 and version2
> models, which mean, if I take your example, that once loaded using EMF you
> can get to your "UpdateAttribute" instance, and then
>
> UpdateAttribute myUpdateDiff =.... // you can browse the diff model and
> find back this element using the EMF eAllContents() for instance.
>
> EStructuralFeature updatedFeature = myUpdateDiff.getAttribute();
> Object oldValue= myUpdateDiff.getLeftElement().eGet(updatedFeature);
> Object newValue= myUpdateDiff.getRightElement().eGet(updatedFeature);
>
> I strongly advise you to use the model loaded thanks to EMF instead of
> working on the XML level as the references resolving can be quite tricky is
> you do it "by hand".
>
> You'll find an example of a customized diff export in the modeling CVS
> (dev.eclipse.org cvsroot=/cvsroot/modeling) called
> org.eclipse.emf.compare.example.export.library and the corresponding
> documentation in the Eclipse help "Adding new actions to the export menu".
>
> For the next (Ganymede +1) release we'll work on a "self contained diff" you
> could apply on other models - which makes it a kind of "patch"
> or "changeset", but then it's more about re-applying/undoing changes than
> about leveraging the diff.
>
> Cheers,
>
> Cédric
>
> jason henriksen wrote:
>
>
>> Hi all,
>>
>> I guess I slightly mis-understood what compare would do for me. I'm
>> wondering if I'm just not using it correctly or there's some parameter
>> that I could set.
>>
>> Right now I'm comparing two an old version of an object and a new
>> version of an object. I'd like to get the diff so that I can build an
>> object log.
>>
>> After my compare I get this XML
>>
>> <diff:ModelInputSnapshot xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
>> <diff left="original.xml" right="altered.xml">
>> <ownedElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
>> <leftElement href="original.xml#/"/>
>> <rightElement href="altered.xml#/"/>
>> </subDiffElements>
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute href="http://model.lab.vsp.com#//Lab/labType"/>
>> <leftElement href="original.xml#/"/>
>> <rightElement href="altered.xml#/"/>
>> </subDiffElements>
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Affiliation/affiliationType"/>
>> <leftElement href="original.xml#//@affiliationList.0"/>
>> <rightElement href="altered.xml#//@affiliationList.0"/>
>> </subDiffElements>
>> <leftParent href="original.xml#//@affiliationList.0"/>
>> </subDiffElements>
>> <subDiffElements xsi:type="diff:AddModelElement">
>> <leftParent href="original.xml#/"/>
>> <rightElement href="altered.xml#//@contactList.2"/>
>> </subDiffElements>
>> <leftParent href="original.xml#/"/>
>> </subDiffElements>
>> </ownedElements>
>> </diff>
>> </diff:ModelInputSnapshot>
>>
>> Let's focus on the updated attribute:
>>
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
>> <leftElement href="original.xml#/"/>
>> <rightElement href="altered.xml#/"/>
>> </subDiffElements>
>>
>> I had thought that the diff would display the old VALUE of the
>> attribute, not just the resource that it's located in. The old resource
>> will be getting deleted momentarily and replaced with the new one so I
>> wont have it to refer back to.
>>
>> This is still somewhat helpful because I can see what was changed, but I
>> don't have any idea what it used to be. I'd love to see something more
>> like this:
>>
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href="http://model.lab.vsp.com#//Lab/labHeadquarterId"/>
>> <leftElement href="original.xml#/" value="AAA"/>
>> <rightElement href="altered.xml#/" value="BBB"/>
>> </subDiffElements>
>>
>>
>> Certainly I can see how this request is tricky. In cases where a whole
>> sub-object was deleted what would be stored? I'm not sure.
>>
>> Is this something that is even remotely possible, or is this kind of a
>> diff outside the current scope of the project?
>>
>> Thanks!
>>
>> Jason Henriksen
>>
>
>


--------------050101070600040804040806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cédric,<br>
<br>
I guess it would be possible to transform a diff model instance into a
ChangeDescription instance...  I.e., it would be possible to create a
ChangeDescription that describes how to turn the left instances into
the right instance as well as one to turn the right instance into the
left instance.  I'm not sure what it would be used for, but it struck
me as potentially interesting since a change description can be applied
to actually make the changes...<br>
<br>
<br>
Cédric Brun wrote:
<blockquote cite="mid:g1o9ou$eo1$1@build.eclipse.org" type="cite">
<pre wrap="">Hi jason,

The XML file EMF compare is providing you is in fact an EMF model, and as
such you can load it using the EMF standards code. That said, the diff
model is referencing both the elements of your version 1 and version2
models, which mean, if I take your example, that once loaded using EMF you
can get to your "UpdateAttribute" instance, and then

UpdateAttribute myUpdateDiff =.... // you can browse the diff model and
find back this element using the EMF eAllContents() for instance.

EStructuralFeature updatedFeature = myUpdateDiff.getAttribute();
Object oldValue= myUpdateDiff.getLeftElement().eGet(updatedFeature);
Object newValue= myUpdateDiff.getRightElement().eGet(updatedFeature);

I strongly advise you to use the model loaded thanks to EMF instead of
working on the XML level as the references resolving can be quite tricky is
you do it "by hand".

You'll find an example of a customized diff export in the modeling CVS
(dev.eclipse.org cvsroot=/cvsroot/modeling) called
org.eclipse.emf.compare.example.export.library and the corresponding
documentation in the Eclipse help "Adding new actions to the export menu".

For the next (Ganymede +1) release we'll work on a "self contained diff" you
could apply on other models - which makes it a kind of "patch"
or "changeset", but then it's more about re-applying/undoing changes than
about leveraging the diff.

Cheers,

Cédric

jason henriksen wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hi all,

I guess I slightly mis-understood what compare would do for me. I'm
wondering if I'm just not using it correctly or there's some parameter
that I could set.

Right now I'm comparing two an old version of an object and a new
version of an object. I'd like to get the diff so that I can build an
object log.

After my compare I get this XML

&lt;diff:ModelInputSnapshot xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xmlns:diff=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/compare/diff/1.1">"http://www.eclipse.org/emf/compare/diff/1.1"</a>&gt;
&lt;diff left="original.xml" right="altered.xml"&gt;
&lt;ownedElements xsi:type="diff:DiffGroup"&gt;
&lt;subDiffElements xsi:type="diff:DiffGroup"&gt;
&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labHeadquarterId">"http://model.lab.vsp.com#//Lab/labHeadquarterId"</a>/&gt;
&lt;leftElement href="original.xml#/"/&gt;
&lt;rightElement href="altered.xml#/"/&gt;
&lt;/subDiffElements&gt;
&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labType">"http://model.lab.vsp.com#//Lab/labType"</a>/&gt;
&lt;leftElement href="original.xml#/"/&gt;
&lt;rightElement href="altered.xml#/"/&gt;
&lt;/subDiffElements&gt;
&lt;subDiffElements xsi:type="diff:DiffGroup"&gt;
&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Affiliation/affiliationType">"http://model.lab.vsp.com#//Affiliation/affiliationType"</a>/&gt;
&lt;leftElement href=<a class="moz-txt-link-rfc2396E" href="mailto:original.xml#//@affiliationList.0">"original.xml#//@affiliationList.0 "</a>/&gt;
&lt;rightElement href=<a class="moz-txt-link-rfc2396E" href="mailto:altered.xml#//@affiliationList.0">"altered.xml#//@affiliationList.0 "</a>/&gt;
&lt;/subDiffElements&gt;
&lt;leftParent href=<a class="moz-txt-link-rfc2396E" href="mailto:original.xml#//@affiliationList.0">"original.xml#//@affiliationList.0 "</a>/&gt;
&lt;/subDiffElements&gt;
&lt;subDiffElements xsi:type="diff:AddModelElement"&gt;
&lt;leftParent href="original.xml#/"/&gt;
&lt;rightElement href=<a class="moz-txt-link-rfc2396E" href="mailto:altered.xml#//@contactList.2">"altered.xml#//@contactList.2 "</a>/&gt;
&lt;/subDiffElements&gt;
&lt;leftParent href="original.xml#/"/&gt;
&lt;/subDiffElements&gt;
&lt;/ownedElements&gt;
&lt;/diff&gt;
&lt;/diff:ModelInputSnapshot&gt;

Let's focus on the updated attribute:

&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labHeadquarterId">"http://model.lab.vsp.com#//Lab/labHeadquarterId"</a>/&gt;
&lt;leftElement href="original.xml#/"/&gt;
&lt;rightElement href="altered.xml#/"/&gt;
&lt;/subDiffElements&gt;

I had thought that the diff would display the old VALUE of the
attribute, not just the resource that it's located in. The old resource
will be getting deleted momentarily and replaced with the new one so I
wont have it to refer back to.

This is still somewhat helpful because I can see what was changed, but I
don't have any idea what it used to be. I'd love to see something more
like this:

&lt;subDiffElements xsi:type="diff:UpdateAttribute"&gt;
&lt;attribute
href=<a class="moz-txt-link-rfc2396E" href="http://model.lab.vsp.com#//Lab/labHeadquarterId">"http://model.lab.vsp.com#//Lab/labHeadquarterId"</a>/&gt;
&lt;leftElement href="original.xml#/" value="AAA"/&gt;
&lt;rightElement href="altered.xml#/" value="BBB"/&gt;
&lt;/subDiffElements&gt;


Certainly I can see how this request is tricky. In cases where a whole
sub-object was deleted what would be stored? I'm not sure.

Is this something that is even remotely possible, or is this kind of a
diff outside the current scope of the project?

Thanks!

Jason Henriksen
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>

--------------050101070600040804040806--
Re: [Compare] is it possible for the diff to hold the old values? [message #619135 is a reply to message #124014] Mon, 02 June 2008 11:37 Go to previous message
Moritz Eysholdt is currently offline Moritz EysholdtFriend
Messages: 161
Registered: July 2009
Location: Kiel, Germany
Senior Member
Hi Cédric,

> For the next (Ganymede +1) release we'll work on a "self contained diff" you
> could apply on other models - which makes it a kind of "patch"
> or "changeset", but then it's more about re-applying/undoing changes than
> about leveraging the diff.

that sounds useful for me, too. Is there already a bug for it where I
can add myself to the CC-list?

regards,
Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #619137 is a reply to message #124066] Mon, 02 June 2008 12:07 Go to previous message
Moritz Eysholdt is currently offline Moritz EysholdtFriend
Messages: 161
Registered: July 2009
Location: Kiel, Germany
Senior Member
Hi Ed, hi Cédric,

> I guess it would be possible to transform a diff model instance into a
> ChangeDescription instance... I.e., it would be possible to create a
> ChangeDescription that describes how to turn the left instances into the
> right instance as well as one to turn the right instance into the left
> instance. I'm not sure what it would be used for, but it struck me as
> potentially interesting since a change description can be applied to
> actually make the changes...

I've just run into a situation where I needed what you described. I'm
about to implement some refactorings for Ecore and my current approach
looks like this:

I'm creating a ChangeDescription model by hand (instead of recording it)
within the RefactoringProcessor. To execute the refactoring I only need
to apply the ChangeDescription.

To have a EMF Compare-based perview within the refactoring wizard, I
generate the needed MatchModel like this:

public static MatchModel createMatchModel(EObject left,
ChangeDescription change) {

change.applyAndReverse();

EObject right = EcoreUtil.copy(left);
URI leftUri = left.eResource().getURI();
URI rightUri = URI.createURI(leftUri + "-tmp."
+ leftUri.fileExtension());
ModelUtils.attachResource(rightUri, right);

change.applyAndReverse();

try {
return MatchService.doContentMatch(left, right, null);
} catch (InterruptedException e) {
e.printStackTrace();
return null;
}
}

After applying the change it copies the model and undoes the change
again. This works for a prototype, but it has some disatvantages:

- The actual model is beeing changed just to generate the preview. It
shouldn't be necessary to touch the model for that.
- I haven't looked into the complexity of the match-model yet, but I've
got the feeling that it might be more efficient to derive it derectly
from the ChangeDescription instead of doing all the comparison again.
- If I create a change by hand, I 'know' what is a 'move' and I don't
need an algorithm to make guesses about it...


suggestions?

regards,
Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #619138 is a reply to message #124813] Mon, 02 June 2008 10:31 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31009
Registered: July 2009
Senior Member
Moritz,

Comments below.

Moritz Eysholdt wrote:
> Hi Ed, hi Cédric,
>
>> I guess it would be possible to transform a diff model instance into
>> a ChangeDescription instance... I.e., it would be possible to create
>> a ChangeDescription that describes how to turn the left instances
>> into the right instance as well as one to turn the right instance
>> into the left instance. I'm not sure what it would be used for, but
>> it struck me as potentially interesting since a change description
>> can be applied to actually make the changes...
>
> I've just run into a situation where I needed what you described. I'm
> about to implement some refactorings for Ecore and my current approach
> looks like this:
>
> I'm creating a ChangeDescription model by hand (instead of recording
> it) within the RefactoringProcessor. To execute the refactoring I only
> need to apply the ChangeDescription.
>
> To have a EMF Compare-based perview within the refactoring wizard, I
> generate the needed MatchModel like this:
>
> public static MatchModel createMatchModel(EObject left,
> ChangeDescription change) {
>
> change.applyAndReverse();
>
> EObject right = EcoreUtil.copy(left);
> URI leftUri = left.eResource().getURI();
> URI rightUri = URI.createURI(leftUri + "-tmp."
> + leftUri.fileExtension());
> ModelUtils.attachResource(rightUri, right);
>
> change.applyAndReverse();
>
> try {
> return MatchService.doContentMatch(left, right, null);
> } catch (InterruptedException e) {
> e.printStackTrace();
> return null;
> }
> }
>
> After applying the change it copies the model and undoes the change
> again. This works for a prototype, but it has some disatvantages:
>
> - The actual model is beeing changed just to generate the preview. It
> shouldn't be necessary to touch the model for that.
What if you did an EcoreUtil.copyAll on the change description and the
final version and used applyAndReverse on that to get the original?
> - I haven't looked into the complexity of the match-model yet, but
> I've got the feeling that it might be more efficient to derive it
> derectly from the ChangeDescription instead of doing all the
> comparison again.
I can imagine that's true. So you'd really like something that did
ChangeDescription -> MatchModel. But of course the ChangeDescription
model relies on there being only one instance model's changes being
described while the MatchModel relies on there being two different
instances. Certainly it's easy to use a Copier to end up with two
corresponding identical instances and from there I imagine it ought to
be possible to directly convert between a ChangeDescription and a
MatchModel...
> - If I create a change by hand, I 'know' what is a 'move' and I don't
> need an algorithm to make guesses about it...
One of the hard problems in comparison is establishing the mapping
between the two instances so given that the underlying Copier uses by
EcoreUtil.copy/copyAll knows that correspondence exactly, at least that
information ought to be reused.
>
>
> suggestions?
It sounds like there are some interesting utilities that could be
explored...
>
> regards,
> Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #619139 is a reply to message #124787] Mon, 02 June 2008 10:34 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31009
Registered: July 2009
Senior Member
Cédric,

I guess that would make it work pretty much exactly like a change
description. Perhaps two way mapping between ChangeDescription <->
MatchModel would be quite an interesting problem to solve. With the
release over soon, maybe I'll have some time to help explore that...


Moritz Eysholdt wrote:
> Hi Cédric,
>
>> For the next (Ganymede +1) release we'll work on a "self contained
>> diff" you
>> could apply on other models - which makes it a kind of "patch"
>> or "changeset", but then it's more about re-applying/undoing changes
>> than
>> about leveraging the diff.
>
> that sounds useful for me, too. Is there already a bug for it where I
> can add myself to the CC-list?
>
> regards,
> Moritz
Re: [Compare] is it possible for the diff to hold the old values? [message #619145 is a reply to message #124837] Mon, 02 June 2008 12:44 Go to previous message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi Ed

You're right when you says the changemodel could be considered for these
changesets, and we would like to provide conversion utility for
changemodel<->diffmodel or changemodel<->matchmodel (once models are copied
and the copier is used to produce the matchmodel).

Moreover the "self contained" changeset model, we want to be able to apply
it on a model who have changed over time, a bit like the "fuzzy" search
mode of a textual patch. Then we'll probably ends up with some kind of
container keeping data to find the new root to apply on + the given
changeset.

That's indeed interesting areas to explore :)

I'll trigger a bug to track all the evolution about this subject.

Cédric


Ed Merks wrote:

> Cédric,
>
> I guess that would make it work pretty much exactly like a change
> description. Perhaps two way mapping between ChangeDescription <->
> MatchModel would be quite an interesting problem to solve. With the
> release over soon, maybe I'll have some time to help explore that...
>
>
> Moritz Eysholdt wrote:
>> Hi Cédric,
>>
>>> For the next (Ganymede +1) release we'll work on a "self contained
>>> diff" you
>>> could apply on other models - which makes it a kind of "patch"
>>> or "changeset", but then it's more about re-applying/undoing changes
>>> than
>>> about leveraging the diff.
>>
>> that sounds useful for me, too. Is there already a bug for it where I
>> can add myself to the CC-list?
>>
>> regards,
>> Moritz


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: [Compare] is it possible for the diff to hold the old values? [message #619148 is a reply to message #124825] Mon, 02 June 2008 17:13 Go to previous message
Moritz Eysholdt is currently offline Moritz EysholdtFriend
Messages: 161
Registered: July 2009
Location: Kiel, Germany
Senior Member
Hi Ed,

thanks for your quick answer.

>> - The actual model is beeing changed just to generate the preview. It
>> shouldn't be necessary to touch the model for that.
> What if you did an EcoreUtil.copyAll on the change description and the
> final version and used applyAndReverse on that to get the original?

thanks for the hint, now

public static EObject copyAndApply(EObject obj, ChangeDescription change) {
EcoreUtil.Copier cop = new Copier();
EObject r = cop.copy(obj);
ChangeDescription c = (ChangeDescription) cop.copy(change);
cop.copyReferences();
c.apply();
return r;
}

public static MatchModel createMatchModel2(EObject left,
ChangeDescription change) {

EObject right = copyAndApply(left, change);

URI leftUri = left.eResource().getURI();
URI rightUri = URI.createURI(leftUri + "-tmp."
+ leftUri.fileExtension());
ModelUtils.attachResource(rightUri, right);

try {
return MatchService.doContentMatch(left, right, null);
} catch (InterruptedException e) {
e.printStackTrace();
return null;
}
}

works for me.

regards,
Moritz


>> - I haven't looked into the complexity of the match-model yet, but
>> I've got the feeling that it might be more efficient to derive it
>> derectly from the ChangeDescription instead of doing all the
>> comparison again.
> I can imagine that's true. So you'd really like something that did
> ChangeDescription -> MatchModel. But of course the ChangeDescription
> model relies on there being only one instance model's changes being
> described while the MatchModel relies on there being two different
> instances. Certainly it's easy to use a Copier to end up with two
> corresponding identical instances and from there I imagine it ought to
> be possible to directly convert between a ChangeDescription and a
> MatchModel...
>> - If I create a change by hand, I 'know' what is a 'move' and I don't
>> need an algorithm to make guesses about it...
> One of the hard problems in comparison is establishing the mapping
> between the two instances so given that the underlying Copier uses by
> EcoreUtil.copy/copyAll knows that correspondence exactly, at least that
> information ought to be reused.
>>
>>
>> suggestions?
> It sounds like there are some interesting utilities that could be
> explored...
>>
>> regards,
>> Moritz
Previous Topic:[Teneo] Switch to DB2 and not getting identity columns
Next Topic:[Teneo] ClassCastException from hibernate trying to persist a new EMap entry with containement=true.
Goto Forum:
  


Current Time: Wed Apr 01 17:26:41 GMT 2020

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

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

Back to the top