Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » migration: EString attribute to ERference
migration: EString attribute to ERference [message #1398837] Fri, 11 July 2014 17:24 Go to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Hi,

From version n to version n+1, an EAttribute of type EString is changed
to be a EReference. The original string attribute is moved into a newly
allocated object that's then set as the reference value (no worries,
containment is handled too).

I do this in a customized XMLHandler.handleForwardReferences(), and that
seems to work for simple test cases. But is there a guarantee that it
works for arbitrary content, or is there a possibility that
deserialisation bails out earlier, say because the attribute value
cannot ever be a reference to another object because of serialization
constraints for EReferences that I'm unaware of?

Thanks for comments,
Felix
Re: migration: EString attribute to ERference [message #1400384 is a reply to message #1398837] Mon, 14 July 2014 05:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30559
Registered: July 2009
Senior Member
Felix,

It depends on the string value itself. If it contains a #, it will look
like a proxy URI and be treated as such. If it contains a ":" it will
look like a QName and will be looked up as type type of object to create
for the following value. If it just looks like an ID, then it will be
looked up...

On 11/07/2014 7:24 PM, Felix Dorner wrote:
> Hi,
>
> From version n to version n+1, an EAttribute of type EString is
> changed to be a EReference. The original string attribute is moved
> into a newly allocated object that's then set as the reference value
> (no worries, containment is handled too).
>
> I do this in a customized XMLHandler.handleForwardReferences(), and
> that seems to work for simple test cases. But is there a guarantee
> that it works for arbitrary content, or is there a possibility that
> deserialisation bails out earlier, say because the attribute value
> cannot ever be a reference to another object because of serialization
> constraints for EReferences that I'm unaware of?
>
> Thanks for comments,
> Felix
Re: migration: EString attribute to ERference [message #1400450 is a reply to message #1400384] Mon, 14 July 2014 08:03 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Hello,

On 14/07/2014 07:58, Ed Merks wrote:
> It depends on the string value itself. If it contains a #, it will look
> like a proxy URI and be treated as such. If it contains a ":" it will
> look like a QName and will be looked up as type type of object to create
> for the following value. If it just looks like an ID, then it will be
> looked up...

Yes I've seen that there's more behind it. Another issue is whitespace..
The attribute contains simple text, so each token is treated as a
separate reference which is not what I want. I checked the next method
higher up would be setValueFromId. I'll see if I can handle it better
from there.

A different idea I had was if I could maybe use extended metadata to
"protect" the reference from being set by mapping it to some dummy name,
then, record unknown features to conserve the attribute value, and set
the reference afterwards. Would that make sense to you?

Felix
Re: migration: EString attribute to ERference [message #1400496 is a reply to message #1400450] Mon, 14 July 2014 09:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30559
Registered: July 2009
Senior Member
Felix,

Comments below.

On 14/07/2014 10:03 AM, Felix Dorner wrote:
> Hello,
>
> On 14/07/2014 07:58, Ed Merks wrote:
>> It depends on the string value itself. If it contains a #, it will look
>> like a proxy URI and be treated as such. If it contains a ":" it will
>> look like a QName and will be looked up as type type of object to create
>> for the following value. If it just looks like an ID, then it will be
>> looked up...
>
> Yes I've seen that there's more behind it. Another issue is
> whitespace.. The attribute contains simple text, so each token is
> treated as a separate reference which is not what I want. I checked
> the next method higher up would be setValueFromId. I'll see if I can
> handle it better from there.
Exactly.
>
> A different idea I had was if I could maybe use extended metadata to
> "protect" the reference from being set by mapping it to some dummy
> name, then, record unknown features to conserve the attribute value,
> and set the reference afterwards. Would that make sense to you?
Yes, though probably more direct would have been to leave the old
attribute in the model, deprecate it, make it transient, suppress its
visibility, and then transform the value in that attribute to a
reference, perhaps as a post load step or perhaps directly in the
attribute's setter, all without messing with the deserializer.
>
> Felix
>
>
Re: migration: EString attribute to ERference [message #1400505 is a reply to message #1400450] Mon, 14 July 2014 09:47 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
On 14/07/2014 10:03, Felix Dorner wrote:

> A different idea I had was if I could maybe use extended metadata to
> "protect" the reference from being set by mapping it to some dummy name,
> then, record unknown features to conserve the attribute value, and set
> the reference afterwards. Would that make sense to you?

That doesn't work. The fallback looks at the Eclass/feature pair and
returns the feature, even if it is mapped to a different name in
ExtendedMetadata. Ok, no problem.

Felix
Re: migration: EString attribute to ERference [message #1400509 is a reply to message #1400496] Mon, 14 July 2014 09:50 Go to previous message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
On 14/07/2014 11:34, Ed Merks wrote:

> Yes, though probably more direct would have been to leave the old
> attribute in the model, deprecate it, make it transient, suppress its
> visibility, and then transform the value in that attribute to a
> reference, perhaps as a post load step or perhaps directly in the
> attribute's setter, all without messing with the deserializer.

That sounds very nice too.
Previous Topic:Sending and receiving XMIResources over network
Next Topic:[XCORE] How to customize/override attribute getter/setter ?
Goto Forum:
  


Current Time: Wed Oct 23 20:33:36 GMT 2019

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

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

Back to the top