Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EcoreUtil.Copier and UUID
EcoreUtil.Copier and UUID [message #402532] Thu, 20 July 2006 12:01 Go to next message
Alex is currently offline AlexFriend
Messages: 65
Registered: July 2009
Member
Dear all,

i'm trying to implement the SaveAs functionality for my gef editor that is
managing an emf model.

I've used EcoreUtil.Copier functionality to clone the object of my model
that will be persisted in a new emf resource and it works greatly. The
problem rise from the fact that i'm using resource with UUID URI and so
the source and target file are semantically equivalent but have different
object URI (since they are generated by the two different resources).

I would like to maintain the same URI in both cases (since they are used
to generate other stuff). Is it there a way of managing this?

TIA
Re: EcoreUtil.Copier and UUID [message #402533 is a reply to message #402532] Thu, 20 July 2006 12:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Alex,

UUID stands for universally unique identifier, so having two instances
with the same UUID is a contradiction. If you modeled the objects to
have an ID attribute (EAttribute with isID true), then the IDs would be
copied along with rest of the object's data. If you wanted to create a
new resource that uses the same IDs as another resource, you can use the
map created while copying (see how EcoreUtil.copy uses a Copier, which
is a map) and do XMLResource.getID(original) and then do
XMLResource.setID(copy, <id>).


Alex wrote:
> Dear all,
>
> i'm trying to implement the SaveAs functionality for my gef editor
> that is managing an emf model.
>
> I've used EcoreUtil.Copier functionality to clone the object of my
> model that will be persisted in a new emf resource and it works
> greatly. The problem rise from the fact that i'm using resource with
> UUID URI and so the source and target file are semantically equivalent
> but have different object URI (since they are generated by the two
> different resources).
>
> I would like to maintain the same URI in both cases (since they are
> used to generate other stuff). Is it there a way of managing this?
>
> TIA
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EcoreUtil.Copier and UUID [message #402536 is a reply to message #402533] Thu, 20 July 2006 13:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Ed, Alex,

Would it not be simpler to just change the EMF Resource's URI to the new URI
(for the new file name) and save it? Then there is no copying required at
all. Or, perhaps the situation is complicated by having cross-references
to/from other resources?

Cheers,

Christian


Ed Merks wrote:

> Alex,
>
> UUID stands for universally unique identifier, so having two instances
> with the same UUID is a contradiction. If you modeled the objects to
> have an ID attribute (EAttribute with isID true), then the IDs would be
> copied along with rest of the object's data. If you wanted to create a
> new resource that uses the same IDs as another resource, you can use the
> map created while copying (see how EcoreUtil.copy uses a Copier, which
> is a map) and do XMLResource.getID(original) and then do
> XMLResource.setID(copy, <id>).
>
>
> Alex wrote:
>> Dear all,
>>
>> i'm trying to implement the SaveAs functionality for my gef editor
>> that is managing an emf model.
>>
>> I've used EcoreUtil.Copier functionality to clone the object of my
>> model that will be persisted in a new emf resource and it works
>> greatly. The problem rise from the fact that i'm using resource with
>> UUID URI and so the source and target file are semantically equivalent
>> but have different object URI (since they are generated by the two
>> different resources).
>>
>> I would like to maintain the same URI in both cases (since they are
>> used to generate other stuff). Is it there a way of managing this?
>>
>> TIA
>>
Re: EcoreUtil.Copier and UUID [message #402803 is a reply to message #402536] Wed, 02 August 2006 15:15 Go to previous messageGo to next message
Alex is currently offline AlexFriend
Messages: 65
Registered: July 2009
Member
Hi all,

Christian,
thanks for you suggestion! Sometime the easiest way is the best one. At
the moment i'm managing just one resource so there are no
cross-referencing problems. BTW could you explain just a bit what kind of
problem you are expecting in that configuration?

Ed,
i know that UUID should be unique but i think that the SaveAs semantic is
something like this: "save what i'm working on with this file name". After
that i expect that the savedAs file could be used where the original one
could (except for change made only into the savedAs, of course). In my
application the saved emf file is the source for a set of other processes
(that rely on the UUID of the emf objects for tracking purpose), so having
different files that share UUID is something i wish to achieve. In any
case i don't see any particular problem with this, do you?
In the meantime i've tried copying my model using the EcoreUtil.Copier as
you suggested but i've got a problem. For some of my emf object i have
modified the *impl file adding some logic and some fields. These fields
are 'service' ones so they are not exported into emf objects interface.
The point is that the copier work only on the interface (as expected) so
this field are not copied during the process, leading to problems. Summing
up, if i want to use the copier i need to define everything into emf
interfaces. But this will clutter them with object that shouldn't really
be visible at that level. What is the recommended way to handle this?

Best regards
Re: EcoreUtil.Copier and UUID [message #402806 is a reply to message #402803] Wed, 02 August 2006 15:43 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Alex,

I think Christian is just suggesting that you can do Resource.setURI to
change the URI and then save that resource and save all the resources
that reference it so that they serialize to reference via the new URI.

It's fine to have two different resources with the same IDs, so that's
not a problem.

Yes, the copier relies on all the information being reflectively
visible. But you can have features for which the accessors don't appear
in the API by using EAnnotations to suppress then (as created by
EcoreUtil.setSuppressedVisibility).



Alex wrote:

> Hi all,
>
> Christian, thanks for you suggestion! Sometime the easiest way is the
> best one. At the moment i'm managing just one resource so there are no
> cross-referencing problems. BTW could you explain just a bit what kind
> of problem you are expecting in that configuration?
>
> Ed, i know that UUID should be unique but i think that the SaveAs
> semantic is something like this: "save what i'm working on with this
> file name". After that i expect that the savedAs file could be used
> where the original one could (except for change made only into the
> savedAs, of course). In my application the saved emf file is the
> source for a set of other processes (that rely on the UUID of the emf
> objects for tracking purpose), so having different files that share
> UUID is something i wish to achieve. In any case i don't see any
> particular problem with this, do you?
> In the meantime i've tried copying my model using the EcoreUtil.Copier
> as you suggested but i've got a problem. For some of my emf object i
> have modified the *impl file adding some logic and some fields. These
> fields are 'service' ones so they are not exported into emf objects
> interface. The point is that the copier work only on the interface (as
> expected) so this field are not copied during the process, leading to
> problems. Summing up, if i want to use the copier i need to define
> everything into emf interfaces. But this will clutter them with object
> that shouldn't really be visible at that level. What is the
> recommended way to handle this?
>
> Best regards
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EcoreUtil.Copier and UUID [message #402831 is a reply to message #402803] Thu, 03 August 2006 18:17 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Alex,

The problem that I anticipate is that, if you have other resources open in
your resource set, and these resources reference the one that you're
"saving as", then these other resources will be *changed* the next time
they are saved, to store HREFs to the newly "saved as" resource. That
probably is not what you want in a "save as" operation.

However, as long as your resources are self-contained, then there's no
reason (that I know of) why this strategy should not work.

Cheers,

Christian


Alex wrote:

> Hi all,
>
> Christian,
> thanks for you suggestion! Sometime the easiest way is the best one. At
> the moment i'm managing just one resource so there are no
> cross-referencing problems. BTW could you explain just a bit what kind of
> problem you are expecting in that configuration?
>
> Ed,
> i know that UUID should be unique but i think that the SaveAs semantic is
> something like this: "save what i'm working on with this file name". After
> that i expect that the savedAs file could be used where the original one
> could (except for change made only into the savedAs, of course). In my
> application the saved emf file is the source for a set of other processes
> (that rely on the UUID of the emf objects for tracking purpose), so having
> different files that share UUID is something i wish to achieve. In any
> case i don't see any particular problem with this, do you?
> In the meantime i've tried copying my model using the EcoreUtil.Copier as
> you suggested but i've got a problem. For some of my emf object i have
> modified the *impl file adding some logic and some fields. These fields
> are 'service' ones so they are not exported into emf objects interface.
> The point is that the copier work only on the interface (as expected) so
> this field are not copied during the process, leading to problems. Summing
> up, if i want to use the copier i need to define everything into emf
> interfaces. But this will clutter them with object that shouldn't really
> be visible at that level. What is the recommended way to handle this?
>
> Best regards
Previous Topic:SaxWrapper
Next Topic:[Announce] EMF 2.2.1 M200608030000 is available
Goto Forum:
  


Current Time: Thu Apr 25 09:19:01 GMT 2024

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

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

Back to the top