Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Change in EMF Reference Navigability
Change in EMF Reference Navigability [message #509327] Fri, 22 January 2010 00:28 Go to next message
Hemant Kolwalkar is currently offline Hemant Kolwalkar
Messages: 15
Registered: July 2009
Junior Member
Hi,

we have an EMF model in which we had the following reference :

A (1) ----------> (1) B (Older version)

we now changed the reference to be bi-directional as below:

A (1) ----------- (1) B (Current version)

after the change when any existing resource (created using the older version EMF model) is loaded, although both A and B get loaded, the reference between A and B is not created.

i tracked the cause down to the XMLHandler.setValueFromId() method.

if my understanding of the method is right, the reference is created (mustAdd=true) only if the reference is uni-directional or it is a bi-directional with cardinality
of A (1) ------- (*) B.

for our case of A (1) ----------- (1) B, since the reference is bi-directional with cardinality of A (1) ------- (1) B, the reference creation seems to be deferred till B is loaded.

while loading an existing resource (created using the prior EMF model), B does not know about the reference to A as the reference was initially uni-directional. as such, although
B gets loaded the reference to A is not created since the information is absent in the resource.

i would like some guidance on how to solve this issue.

one approach i can think of is to extend the XMLHandler and override the setValueFromId() method. but inorder to do that, i would like to have some insight on the existing implementation rationale and whether it is by intention or an oversight.

a second approach would be to set the option deferIDREFResolution=true while loading the resource.
that would set the mustAdd=true flag and force the creation of the reference.

any other suggestions would be much appreciated.

thanks,

- Hemant


Re: Change in EMF Reference Navigability [message #509399 is a reply to message #509327] Fri, 22 January 2010 06:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
Hemant,

Comments below.

Hemant Kolwalkar wrote:
> Hi,
>
> we have an EMF model in which we had the following reference :
>
> A (1) ----------> (1) B (Older version)
>
> we now changed the reference to be bi-directional as below:
>
> A (1) ----------- (1) B (Current version)
>
> after the change when any existing resource (created using the older
> version EMF model) is loaded, although both A and B get loaded, the
> reference between A and B is not created.
>
> i tracked the cause down to the XMLHandler.setValueFromId() method.
> if my understanding of the method is right, the reference is created
> (mustAdd=true) only if the reference is uni-directional or it is a
> bi-directional with cardinality
> of A (1) ------- (*) B.
>
> for our case of A (1) ----------- (1) B, since the reference is
> bi-directional with cardinality of A (1) ------- (1) B, the reference
> creation seems to be deferred till B is loaded.
> while loading an existing resource (created using the prior EMF
> model), B does not know about the reference to A as the reference was
> initially uni-directional. as such, although
> B gets loaded the reference to A is not created since the information
> is absent in the resource.
>
> i would like some guidance on how to solve this issue.
> one approach i can think of is to extend the XMLHandler and override
> the setValueFromId() method. but inorder to do that, i would like to
> have some insight on the existing implementation rationale and whether
> it is by intention or an oversight.
>
> a second approach would be to set the option deferIDREFResolution=true
> while loading the resource.
> that would set the mustAdd=true flag and force the creation of the
> reference.
>
> any other suggestions would be much appreciated.
Do these references need to span resources? If not, you should consider
making the B -> A reference transient. Then the other end will be set
and that will populate both ends.
>
> thanks,
>
> - Hemant
>
>
>
Re: Change in EMF Reference Navigability [message #509719 is a reply to message #509399] Mon, 25 January 2010 08:11 Go to previous message
Hemant Kolwalkar is currently offline Hemant Kolwalkar
Messages: 15
Registered: July 2009
Junior Member
Hi Ed,

the reference would not need to span resources with our current usage but one cannot rule it out the possibility in future.

as you suggested, i did try by setting B -> A reference transient in the Rose model. but when i tried to reload the genmodel, i get the error message "Cross document bidirectional reference must not be transient; reference 'B' -> 'A' ".

also would'nt setting to "transient =true" exclude the reference from serialization to the resource? if thats rue then that approach may not work for our use-case.

what is your take on the deferIDREFResolution=true approach? from the documentation, doing so also would help in improving loading performance is definitely welcome. any downsides to using the deferIDREFResolution?

thanks,

- Hemant
Re: Change in EMF Reference Navigability [message #509747 is a reply to message #509719] Mon, 25 January 2010 05:00 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
Hermant,

Comments below.

Hemant Kolwalkar wrote:
> Hi Ed,
>
> the reference would not need to span resources with our current usage
> but one cannot rule it out the possibility in future.
>
> as you suggested, i did try by setting B -> A reference transient in
> the Rose model. but when i tried to reload the genmodel, i get the
> error message "Cross document bidirectional reference must not be
> transient; reference 'B' -> 'A' ".
>
> also would'nt setting to "transient =true" exclude the reference from
> serialization to the resource? if thats rue then that approach may not
> work for our use-case.
You'd also need to turn off proxy resolving, that's why I was asking
about the need for cross document references.
>
> what is your take on the deferIDREFResolution=true approach?
That won't help the cross document case. In that case you must have a
proxy at both ends and since your older serialization doesn't include
that, you'll have to do more than just fiddle with the model's settings.
> from the documentation, doing so also would help in improving loading
> performance is definitely welcome. any downsides to using the
> deferIDREFResolution?
It has to build a table so will use more memory, but if there are lots
of forward references, it has to do that anyway.
>
> thanks,
>
> - Hemant
>
Previous Topic:Get rid of Example EMF Model Creation Wizards
Next Topic:NullPointer at org.eclipse.emf.common.EMFPlugin$InternalHelper.log(EMFPlugin.java:736)
Goto Forum:
  


Current Time: Sat Oct 25 06:37:50 GMT 2014

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

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