Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » persisting unchangeable attributes(loading a resource that includes values for unchangeable attributes throws an error)
icon5.gif  persisting unchangeable attributes [message #504804] Tue, 22 December 2009 18:40 Go to next message
Greg Mising name is currently offline Greg Mising nameFriend
Messages: 47
Registered: July 2009
Member
Here's my scenario. I want the id attribute for my objects to be unchangeable, mostly so that I can use the ECoreUtil.copy() function to get copies with unique ids, but also because the values should not be editable in general.

When I try to create or load a model from a resource (using the default xml resource handler and new model wizard) then I get an invalid argument exception thrown because it is calling eSet for the id feature.

Should I override XMLHandler or use a custom XMIHelper to create the object and handle initialization of such attributes or should I override eSet for my model object and just have it manually set that feature? So far, I've done the latter since it's quick but it seems dirty.

Any suggestions? Other options? Thanks.

Greg

[Updated on: Tue, 22 December 2009 18:48]

Report message to a moderator

Re: persisting unchangeable attributes [message #504940 is a reply to message #504804] Wed, 23 December 2009 11:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30687
Registered: July 2009
Senior Member
Greg,

Comments below.

Greg wrote:
> Here's my scenario. I want the id attribute for my objects to be
> unchangeable, mostly so that I can use the ECoreUtil.copy() function
> to get copies with unique ids, but also because the values should not
> be editable in general.
> When I try to create or load a model from a resource (using the
> default xml resource handler and new model wizard) then I get an
> invalid argument exception thrown because it is calling eSet for the
> id feature.
>
> Should I override XMLHandler or use a custom XMIHelper to create the
> object and handle initialization of such attributes or should I
> override eSet for my model object and just have it ignore the request
> to set that feature? So far, I've done the latter since it's quick
> but it seems dirty.
How about marking the feature as transient so it's not persisted?
Likely you do want to read in the from the resource so it's not sensible
to make the feature unchangeable. You could just make the property
descriptor for it read only so that one can't edit it in the editor even
though it's possible via the API. And you could make that more
difficult by suppressing the setter method from the API so it's only
possible to do it via EMF reflection.
>
> Any suggestions? Other options? Thanks.
>
> Greg
Re: persisting unchangeable attributes [message #504949 is a reply to message #504940] Wed, 23 December 2009 17:53 Go to previous message
Greg Mising name is currently offline Greg Mising nameFriend
Messages: 47
Registered: July 2009
Member
Hi Ed. Thanks for replying.

I do want and need to persist this attribute as it is the unique identifier for all of my model's objects. So it is what is used to refer to other objects within the persisted xml document. I have made the property descriptor readonly. If I suppress the setId() method then don't I have to override the eSet() method since it would just call setId() by default? I'd have to change it to manually assign the id so that loading the resource using the reflective method would still work. This is what I've currently done on top of setting the attribute as non-changeable. In my solution there is no setId() method generated and I have to add the relevant case to the eSet() method. The side-effect of setting the attribute as non-changeable is that calling EcoreUtil.copy( myObject ) gives me a copy of my object with a unique id attribute. From what I understand, I could get the same result by using a custom EcoreUtil.Copier, but who is going to ensure that the custom copier is always used to copy my objects? Why don't EObjects know how to do a [deep] copy of themselves?

Greg
Re: persisting unchangeable attributes [message #504952 is a reply to message #504949] Wed, 23 December 2009 13:40 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30687
Registered: July 2009
Senior Member
Greg,

Comments below.

Greg wrote:
> Hi Ed. Thanks for replying.
>
> I do want and need to persist this attribute as it is the unique
> identifier for all of my model's objects. So it is what is used to
> refer to other objects within the persisted xml document. I have made
> the property descriptor readonly. If I suppress the setId() method
> then don't I have to override the eSet() method since it would just
> call setId() by default?
Yes.
> I'd have to change it to manually assign the id so that loading the
> resource using the reflective method would still work.
No, there's still a setId method in the AbcImpl it's just suppressed
from the Abc interface, i.e., from the public API.
> This is what I've currently done on top of setting the attribute as
> non-changeable. In my solution there is no setId() method generated
> and I have to add the relevant case to the eSet() method.
That sounds more painful yet equivalent to what I suggested, which is
purely generated. There's an EAnnotation to suppress the ID. The EMF
refcard is useful for such details.
> The side-effect of setting the attribute as non-changeable is that
> calling EcoreUtil.copy( myObject ) gives me a copy of my object with a
> unique id attribute.
The copier doesn't copy derived things though it's not really derived
from anything so I suppose that's not entirely idea.
> From what I understand, I could get the same result by using a custom
> EcoreUtil.Copier, but who is going to ensure that the custom copier is
> always used to copy my objects?
No one will ensure that, but then the general expectation is be that
EcoreUtil.copy will produce something that's EcoreUtil.equals (other
than bidirectional references that can't be copied).
> Why don't EObjects know how to do a [deep] copy of themselves?
Because that's a bunch more byte code that can be accomplished with a
single reflective implementation. You're of course free to implement a
method line clone directly, but even that should produce something
that's equal I think...
>
> Greg
Previous Topic:How to inject ecore:reference with a QName without modifying a xsd
Next Topic:[CDO] Adding different models to the same ResourceNode concurrently
Goto Forum:
  


Current Time: Mon Dec 09 23:04:02 GMT 2019

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

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

Back to the top