|Re: Generating XMI with UUIDs [message #390182 is a reply to message #390179]
||Mon, 27 December 2004 14:40
| Ed Merks
Registered: July 2009
When the useUUIDs method returns true, it will be assumed that the IDs
of objects in the resource are universally unique. Any object removed
from the resource will still remember its UUID and any object attached
to the resource will be assigned a generated UUID, if it doesn't already
have a remembered UUID. Changing this method will have no impact on how
a "standard" XMI file will be parsed. I.e., if the input has UUIDs and
has references to them, those will work regardless of this setting.
The important impact of changing this method is to ensure that every
object is assigned a UUID without having to call XMLResource.setID
explicitly to achieve that. UUIDs are very powerful but tend to cause
Hayden Marchant wrote:
> When I was using the default XMIResourceImpl to persist my model, I
> was getting internal object references resolved like "/i", where 'i'
> was the index of the object in the document. This is not inline with
> how a lot of XMI references are resolved in various XMI standards.
> They normally have xmi:id attributes, and references are to those ids.
> After looking through the source code I noticed the useUuids() method.
> I overode this method to return 'true' and my XMI suddenly looked a
> lot more 'standard'. Is this the correct way to get such
> functionality? If I can do this, it means that I can use EMF to parse
> various vendor-specific XMI files since they generally resolve ids in
> this manner.
Powered by FUDForum
. Page generated in 0.01899 seconds