Eclipse Community Forums: EMF » Reference elements by ID in Ecore model / xmi

Home » Modeling » EMF » Reference elements by ID in Ecore model / xmi(Reference elements by ID in Ecore model / xmi)

Reference elements by ID in Ecore model / xmi [message #1776990]

Thu, 23 November 2017 08:10

Eclipse User

Hi,

I am having a problem with the size of my XMI file that get very big when there are too many elements and relationships that should be defined in the model. I realize that the references between the elements is not happening through the ID that i defined in the meta-model. it is through the path to the object in the model : example ; "//@CompElement.3/@composit/@parts.9". I believe because of this issue, my xmi file is getting very big.

I would like to build the reference across elements using the ID generated when element is created in the model, exactly like the UML model. all association and dependency relationships associate the elements by ID.

Is there is something I can update my model with to be able to reference elements by their IDs and not path.

Regards
Sarah

Re: Reference elements by ID in Ecore model / xmi [message #1776995 is a reply to message #1776990]

Thu, 23 November 2017 08:37

Eclipse User

Hi

Use of a model ID is very vulnerable to the possibly inaccurate uniqueness semantics of the ID. You risk many exciting conflicts between model an serialization usage.

Use of xmi:id can be genuinely unique. You may get a two-fold improvement by using very short xmi:ids that can be a Base64 encoding of a simple integer count. You allocate the xmi:ids just before saving. However unless you have many references per definition and/or very long default paths, you won't do much better than two-fold.

EMF's file compression will be much more effective; XMI files are so repetitious you should get over 90% compression.

But if you really have a size problem, you should perhaps look at multiple small files exploiting EMF's composite resources.

Regards

Ed Willink

Re: Reference elements by ID in Ecore model / xmi [message #1777010 is a reply to message #1776995]

Thu, 23 November 2017 10:10

Eclipse User

"Very big" is rather subjective. What do you consider "very big"? In what way is the size of the file a problem?

In any case, in your resource factory create an XMIResourceIml that overrides this method:

	@Override
	protected boolean useUUIDs() {
		return true;
	}

That will result in UUIDs being assigned when objects are added to the resource. Note that while the serialization will be smaller, the in-memory footprint (for maintaining the two-ID map) will actually be bigger.

Re: Reference elements by ID in Ecore model / xmi [message #1777279 is a reply to message #1777010]

Tue, 28 November 2017 00:08

Eclipse User

hi Ed,

My problem with the size of the file which is 200M , is that it takes time to load it inside the editor . particularly when loading the resource:
resource = editingDomain.getResourceSet().getResource(resourceURI, true);

I created the ID , and I use them as a reference , but still the size of the file is big .

Any possible solution
Sarah

Re: Reference elements by ID in Ecore model / xmi [message #1777305 is a reply to message #1777279]

Tue, 28 November 2017 04:48

Eclipse User

It's impossible to know what might be special about your scenario that might lead to a performance problem and based on that insight might lead to a suggestion. I would try org.eclipse.emf.ecore.xmi.XMLResource.OPTION_DEFER_IDREF_RESOLUTION because if there are many forward references is wasteful to try to resolve them early. Probably OPTION_DEFER_ATTACHMENT won't help at all, but is worth a try. As a save option, OPTION_USE_ENCODED_ATTRIBUTE_STYLE will tend to produce a much more compact serialization.

Alternatively you could use something like BinaryResourceImpl to load and save the instance. A binary a serialization is generally a small fraction of the size of the XML and loads generally an order of magnitude faster, but it's not human readable and would be less than ideal to put under version control.

If you end up needing truly massive amounts of data, you might explore using something like CDO.

Previous Topic:	Problems with EMF compare representations.aird
Next Topic:	[CDO][4.6] Request with lower cased Table Name gives an error

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 20 15:01:14 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter