Home » Modeling » EMF » [EMF] [CDO] [Compare] [Bug?] Compare will not work with certan implementation of EStore
|
| Re: [EMF] [CDO] [Compare] [Bug?] Compare will not work with certan implementation of EStore [message #1221342 is a reply to message #1221331] |
Tue, 17 December 2013 13:24   |
|
Hi Leonid,
I'm confused as to how CDO is related. Can you elaborate? What's the fully qualified name of
ManyStructuralFeatureAccessorImpl?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 17.12.2013 13:49, schrieb Leonid Ripeynih:
> As there is no responce in compare forum, i'm cross-posting it here:
>
> This code (in ManyStructuralFeatureAccessorImpl) may not work if valueOfDiff is a FeatureMap.Entry.
>
> private Diff getDiffWithValue(Object value) {
> Diff ret = null;
> for (Diff diff : getDifferences()) {
> Object valueOfDiff = getValueFromDiff(diff, getSide());
> if (valueOfDiff == value) {
> ret = diff;
> break;
> }
> }
> return ret;
> }
>
>
> Consider an CDO implementation of EStoreEObjectImpl.EStoreFeatureMap which returns a new set of wrappers each time
> it's delegateToArray is called.
>
> Wrappers are perfectly equal, and their wrapped objects are same (theis Values and Feature are same). However,
> wrappers are not same, and comparison by reference (valueOfDiff == value) fails. I suggest changit this to equals (and
> EObject's can not override equals by it's contract, so it will not affect them)
>
> Should I open a bugzilla for it, or is it intended behavior?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | | | | |
| Re: [EMF] [CDO] [Compare] [Bug?] Compare will not work with certan implementation of EStore [message #1221813 is a reply to message #1221763] |
Wed, 18 December 2013 13:25 |
|
Hi, Eike, Leonid,
I suspect that the majority use case for FeatureMaps is to impose an
ordering of intermingled elements in the XML serialization that are
modeled in multiple EStructuralFeatures in the Ecore model. For this
purpose, UML provides a fairly elegant solution in the superset/subset
relationship between properties (although it does add some additional
"weight" in the persisted model, because of the additional references
to objects) that transcends XML.
A superset property can automatically aggregate (and impose an ordering
on) the objects in the properties that are its subsets. Optionally, a
superset can also have objects that are not in any of its subsets.
There are numerous examples of both (plus "derived unions", which
aren't so interesting in this case) in the UML Metamodel.
Since the Kepler release, CDO supports models generated with
superset/subset properties from UML (as an alternative to generating
from Ecore). However, this does require leveraging CDO's "legacy
model" support as CDO Native models don't implement these UML-isms.
Something to think about, at least.
Cheers,
Christian
On 2013-12-18 11:26:20 +0000, Eike Stepper said:
> Am 18.12.2013 10:47, schrieb Leonid Ripeynih:
>> Eike Stepper wrote on Wed, 18 December 2013 03:52
>>> Am 18.12.2013 06:21, That depends on how and for what purpose you're
>>> using feature maps ;)
>>
>>
>> They have originated from XSD -> Ecore transformation during initial
>> model generation. Mostly they're used for representation of
>>
>> <xs:sequence>
>> <xs:choice maxOccures="unbounded"/>
>> </xs:sequence>
>>
>>
>> So, ordered structures without strict type bounds.
> You can probably use EList<EObject>, but it strikes me that it would be
> good to refactor the model to allow for stricter bounds. Hard to tell
> without knowing the model ;-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 19:28:03 GMT 2024
Powered by FUDForum. Page generated in 0.03896 seconds |
] 
Search
Help
Register
Login
Home
