Home » Modeling » EMF » EcoreUtil.Copier and UUID
| |
Re: EcoreUtil.Copier and UUID [message #402536 is a reply to message #402533] |
Thu, 20 July 2006 13:28 |
Eclipse User |
|
|
|
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 #402806 is a reply to message #402803] |
Wed, 02 August 2006 15:43 |
Ed Merks 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 |
Eclipse User |
|
|
|
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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 09:19:01 GMT 2024
Powered by FUDForum. Page generated in 0.03772 seconds
|