Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 13:10 Go to next message
sarah Adam is currently offline sarah AdamFriend
Messages: 5
Registered: March 2017
Junior Member

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 13:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5580
Registered: July 2009
Senior Member
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 15:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29122
Registered: July 2009
Senior Member
"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 05:08 Go to previous messageGo to next message
sarah Adam is currently offline sarah AdamFriend
Messages: 5
Registered: March 2017
Junior Member
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 09:48 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 29122
Registered: July 2009
Senior Member
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:
  


Current Time: Fri Jan 19 01:49:15 GMT 2018

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

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