 persisting unchangeable attributes [message #504804] |
Tue, 22 December 2009 18:40  |
 Greg Mising name
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 #504952 is a reply to message #504949] |
Wed, 23 December 2009 13:40  |
Ed Merks
Messages: 33136
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02011 seconds
] 
Search
Help
Register
Login
Home
