|
|
| Re: persisting unchangeable attributes [message #504949 is a reply to message #504940] |
Wed, 23 December 2009 12:53  |
Eclipse User |
|
|
|
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 08:40 |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.05837 seconds
Home
