Eclipse Community Forums: EMF » Will eStore.get with EStore.NO

Help

Home

Home » Modeling » EMF » Will eStore.get with EStore.NO_INDEX on a many efeature, return a List?

Show: Today's Messages :: Show Polls :: Message Navigator

Will eStore.get with EStore.NO_INDEX on a many efeature, return a List? [message #428236]

Mon, 16 March 2009 08:25

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Eike, Ed,
I have been working with Tom on persisting CDO/EStore objects through Teneo. Teneo needs to have access to the list
instances inside of an EStore, to ensure lazy loading etc.

I use the following call to get to the list itself:
list = (List<?>) eStore.get((InternalEObject) eObject, eref, EStore.NO_INDEX);

Is it indeed correct that I can assume that passing NO_INDEX to an EStore.get should return a List?

Eike, with CDO, I can assume that the underlying (delegated list) will be returned?

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: Will eStore.get with EStore.NO_INDEX on a many efeature, return a List? [message #428237 is a reply to message #428236]

Mon, 16 March 2009 08:34

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Martin,

I followed your effort and some time ago I talked with Ed about the
issue of NO_INDEX in dynamic get() and set().
IIRC it is *not* specified that NO_INDEX grants read or write access to
the list itself. Ed may correct me if I'm wrong.
That said, I can currently not exclude that CDOObjectImpl does behave as
you described in this unspecified case.
Can we wait with the CDO part of the answer until Ed says something
about the general contract?

Cheers
/Eike

----
http://thegordian.blogspot.com

Martin Taal schrieb:
> Hi Eike, Ed,
> I have been working with Tom on persisting CDO/EStore objects through
> Teneo. Teneo needs to have access to the list instances inside of an
> EStore, to ensure lazy loading etc.
>
> I use the following call to get to the list itself:
> list = (List<?>) eStore.get((InternalEObject) eObject, eref,
> EStore.NO_INDEX);
>
> Is it indeed correct that I can assume that passing NO_INDEX to an
> EStore.get should return a List?
>
> Eike, with CDO, I can assume that the underlying (delegated list) will
> be returned?
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Will eStore.get with EStore.NO_INDEX on a many efeature, return a List? [message #428243 is a reply to message #428237]

Mon, 16 March 2009 09:16

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------020300010400090808040709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Guys,

EStoreEObjectImpl implements dynamic get like this:

public Object dynamicGet(int dynamicFeatureID)
{
Object result = eSettings[dynamicFeatureID];
if (result == null)
{
EStructuralFeature eStructuralFeature =
eDynamicFeature(dynamicFeatureID);
if (!eStructuralFeature.isTransient())
{
if (FeatureMapUtil.isFeatureMap(eStructuralFeature))
{
eSettings[dynamicFeatureID] = result =
createFeatureMap(eStructuralFeature);
}
else if (eStructuralFeature.isMany())
{
eSettings[dynamicFeatureID] = result =
createList(eStructuralFeature);
}
else
{
result = eStore().get(this, eStructuralFeature,
InternalEObject.EStore.NO_INDEX);
if (eIsCaching())
{
eSettings[dynamicFeatureID] = result;
}
}
}
}
return result;
}

So for the list case, a list that delegates to the store is created and
hence the store is not expected to be responsible for creating the list
itself. I.e., the EStore.NO_INDEX case is only for single valued features.

/**
* A value indicating that no index is specified.
* It is used in the case of accessing {@link ETypedElement#isMany()
single-valued} features
* where an index would be meaningless.
*/
int NO_INDEX = -1;

Eike Stepper wrote:
> Martin,
>
> I followed your effort and some time ago I talked with Ed about the
> issue of NO_INDEX in dynamic get() and set().
> IIRC it is *not* specified that NO_INDEX grants read or write access
> to the list itself. Ed may correct me if I'm wrong.
> That said, I can currently not exclude that CDOObjectImpl does behave
> as you described in this unspecified case.
> Can we wait with the CDO part of the answer until Ed says something
> about the general contract?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Martin Taal schrieb:
>> Hi Eike, Ed,
>> I have been working with Tom on persisting CDO/EStore objects through
>> Teneo. Teneo needs to have access to the list instances inside of an
>> EStore, to ensure lazy loading etc.
>>
>> I use the following call to get to the list itself:
>> list = (List<?>) eStore.get((InternalEObject) eObject, eref,
>> EStore.NO_INDEX);
>>
>> Is it indeed correct that I can assume that passing NO_INDEX to an
>> EStore.get should return a List?
>>
>> Eike, with CDO, I can assume that the underlying (delegated list)
>> will be returned?
>>

--------------020300010400090808040709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys, 
 
EStoreEObjectImpl implements dynamic get like this: 

<blockquote>  public Object dynamicGet(int dynamicFeatureID) 
  { 
    Object result = eSettings[dynamicFeatureID]; 
    if (result == null) 
    { 
      EStructuralFeature eStructuralFeature =
eDynamicFeature(dynamicFeatureID); 
      if (!eStructuralFeature.isTransient()) 
      { 
          if (FeatureMapUtil.isFeatureMap(eStructuralFeature)) 
          { 
            eSettings[dynamicFeatureID] = result =
createFeatureMap(eStructuralFeature); 
          } 
          else if (eStructuralFeature.isMany()) 
          { 
            eSettings[dynamicFeatureID] = result =
createList(eStructuralFeature); 
          } 
          else 
          { 
            result = eStore().get(this, eStructuralFeature,
InternalEObject.EStore.NO_INDEX); 
            if (eIsCaching()) 
            { 
              eSettings[dynamicFeatureID] = result; 
            } 
          } 
      } 
    } 
    return result; 
  } 
</blockquote>
So for the list case, a list that delegates to the store is created and
hence the store is not expected to be responsible for creating the list
itself.  I.e., the EStore.NO_INDEX case is only for single valued
features. 
 
    /** 
     * A value indicating that no index is specified. 
     * It is used in the case of accessing {@link
ETypedElement#isMany() single-valued} features 
     * where an index would be meaningless. 
     */ 
    int NO_INDEX = -1; 
 
 
Eike Stepper wrote:
<blockquote cite="mid:gpl2vd$luc$2@build.eclipse.org" type="cite">Martin,
 
 
I followed your effort and some time ago I talked with Ed about the
issue of NO_INDEX in dynamic get() and set().
 
IIRC it is *not* specified that NO_INDEX grants read or write access to
the list itself. Ed may correct me if I'm wrong.
 
That said, I can currently not exclude that CDOObjectImpl does behave
as you described in this unspecified case.
 
Can we wait with the CDO part of the answer until Ed says something
about the general contract?
 
 
Cheers
 
/Eike
 
 
----
 
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
 
 
 
 
Martin Taal schrieb:
 
<blockquote type="cite">Hi Eike, Ed,
 
I have been working with Tom on persisting CDO/EStore objects through
Teneo. Teneo needs to have access to the list instances inside of an
EStore, to ensure lazy loading etc.
 
 
I use the following call to get to the list itself:
 
 list = (List<?>) eStore.get((InternalEObject) eObject, eref,
EStore.NO_INDEX);
 
 
Is it indeed correct that I can assume that passing NO_INDEX to an
EStore.get should return a List?
 
 
Eike, with CDO, I can assume that the underlying (delegated list) will
be returned?
 
 
</blockquote>
</blockquote>
</body>
</html>

--------------020300010400090808040709--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Will eStore.get with EStore.NO_INDEX on a many efeature, return a List? [message #428245 is a reply to message #428243]

Mon, 16 March 2009 09:59

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Thanks Ed,
In this case I access the EStore directly, so without going through the EStoreEObjectImpl and there I see this
implementation:
public Object get(InternalEObject eObject, EStructuralFeature feature, int index)
{
Entry entry = new Entry(eObject, feature);
if (index == NO_INDEX)
{
return map.get(entry);
}
else
{
return getList(entry).get(index);
}
}

So if NO_INDEX is passed it returns the value (==List) itself.

The same behavior I see in the CDOStoreSettingsImpl:
public Object get(InternalEObject eObject, EStructuralFeature feature, int index)
{
int dynamicFeatureID = eDynamicFeatureID(eObject, feature);
if (index != NO_INDEX)
{
return getValueAsList(eObject, dynamicFeatureID).get(index);
}

return getValue(eObject, dynamicFeatureID);
}

So from a contract api point of view what do you think that I can expect when calling:
EStore.get(InternalEObject eObject, EStructuralFeature feature, int index)
with index to NO_INDEX?

Ofcourse I hope the answer will be that in this case the EStore should return a List/Collection for many efeatures...
This corresponds to current (accidental) behavior.

gr. Martin

Ed Merks wrote:
> Guys,
>
> EStoreEObjectImpl implements dynamic get like this:
>
> public Object dynamicGet(int dynamicFeatureID)
> {
> Object result = eSettings[dynamicFeatureID];
> if (result == null)
> {
> EStructuralFeature eStructuralFeature =
> eDynamicFeature(dynamicFeatureID);
> if (!eStructuralFeature.isTransient())
> {
> if (FeatureMapUtil.isFeatureMap(eStructuralFeature))
> {
> eSettings[dynamicFeatureID] = result =
> createFeatureMap(eStructuralFeature);
> }
> else if (eStructuralFeature.isMany())
> {
> eSettings[dynamicFeatureID] = result =
> createList(eStructuralFeature);
> }
> else
> {
> result = eStore().get(this, eStructuralFeature,
> InternalEObject.EStore.NO_INDEX);
> if (eIsCaching())
> {
> eSettings[dynamicFeatureID] = result;
> }
> }
> }
> }
> return result;
> }
>
> So for the list case, a list that delegates to the store is created and
> hence the store is not expected to be responsible for creating the list
> itself. I.e., the EStore.NO_INDEX case is only for single valued features.
>
> /**
> * A value indicating that no index is specified.
> * It is used in the case of accessing {@link ETypedElement#isMany()
> single-valued} features
> * where an index would be meaningless.
> */
> int NO_INDEX = -1;
>
>
> Eike Stepper wrote:
>> Martin,
>>
>> I followed your effort and some time ago I talked with Ed about the
>> issue of NO_INDEX in dynamic get() and set().
>> IIRC it is *not* specified that NO_INDEX grants read or write access
>> to the list itself. Ed may correct me if I'm wrong.
>> That said, I can currently not exclude that CDOObjectImpl does behave
>> as you described in this unspecified case.
>> Can we wait with the CDO part of the answer until Ed says something
>> about the general contract?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Martin Taal schrieb:
>>> Hi Eike, Ed,
>>> I have been working with Tom on persisting CDO/EStore objects through
>>> Teneo. Teneo needs to have access to the list instances inside of an
>>> EStore, to ensure lazy loading etc.
>>>
>>> I use the following call to get to the list itself:
>>> list = (List<?>) eStore.get((InternalEObject) eObject, eref,
>>> EStore.NO_INDEX);
>>>
>>> Is it indeed correct that I can assume that passing NO_INDEX to an
>>> EStore.get should return a List?
>>>
>>> Eike, with CDO, I can assume that the underlying (delegated list)
>>> will be returned?
>>>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: Will eStore.get with EStore.NO_INDEX on a many efeature, return a List? [message #428248 is a reply to message #428245]

Mon, 16 March 2009 11:04

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Martin,

Comments below.

Martin Taal wrote:
> Thanks Ed,
> In this case I access the EStore directly, so without going through
> the EStoreEObjectImpl and there I see this implementation:
> public Object get(InternalEObject eObject, EStructuralFeature
> feature, int index)
> {
> Entry entry = new Entry(eObject, feature);
> if (index == NO_INDEX)
> {
> return map.get(entry);
> }
> else
> {
> return getList(entry).get(index);
> }
> }
Yes, but this is just a bogus thing for testing. The list it creates
isn't even an InternalEList, so it's really quite bogus.
>
> So if NO_INDEX is passed it returns the value (==List) itself.
>
> The same behavior I see in the CDOStoreSettingsImpl:
> public Object get(InternalEObject eObject, EStructuralFeature
> feature, int index)
> {
> int dynamicFeatureID = eDynamicFeatureID(eObject, feature);
> if (index != NO_INDEX)
> {
> return getValueAsList(eObject, dynamicFeatureID).get(index);
> }
>
> return getValue(eObject, dynamicFeatureID);
> }
It's certainly not unreasonable that the store could create the list.
(It's just not clear to be yet why it's necessary.)
>
> So from a contract api point of view what do you think that I can
> expect when calling:
> EStore.get(InternalEObject eObject, EStructuralFeature feature, int
> index)
> with index to NO_INDEX?
Some stores might expect that for multi-valued features that there will
always be an index.
>
> Ofcourse I hope the answer will be that in this case the EStore should
> return a List/Collection for many efeatures...
I gather that. :-P I'm curious why though. The list that's being
created delegates all operations onto the store already, so what
additional element of control does having a different list
implementation buy you?
> This corresponds to current (accidental) behavior.
>
> gr. Martin
>
> Ed Merks wrote:
>> Guys,
>>
>> EStoreEObjectImpl implements dynamic get like this:
>>
>> public Object dynamicGet(int dynamicFeatureID)
>> {
>> Object result = eSettings[dynamicFeatureID];
>> if (result == null)
>> {
>> EStructuralFeature eStructuralFeature =
>> eDynamicFeature(dynamicFeatureID);
>> if (!eStructuralFeature.isTransient())
>> {
>> if (FeatureMapUtil.isFeatureMap(eStructuralFeature))
>> {
>> eSettings[dynamicFeatureID] = result =
>> createFeatureMap(eStructuralFeature);
>> }
>> else if (eStructuralFeature.isMany())
>> {
>> eSettings[dynamicFeatureID] = result =
>> createList(eStructuralFeature);
>> }
>> else
>> {
>> result = eStore().get(this, eStructuralFeature,
>> InternalEObject.EStore.NO_INDEX);
>> if (eIsCaching())
>> {
>> eSettings[dynamicFeatureID] = result;
>> }
>> }
>> }
>> }
>> return result;
>> }
>>
>> So for the list case, a list that delegates to the store is created
>> and hence the store is not expected to be responsible for creating
>> the list itself. I.e., the EStore.NO_INDEX case is only for single
>> valued features.
>>
>> /**
>> * A value indicating that no index is specified.
>> * It is used in the case of accessing {@link
>> ETypedElement#isMany() single-valued} features
>> * where an index would be meaningless.
>> */
>> int NO_INDEX = -1;
>>
>>
>> Eike Stepper wrote:
>>> Martin,
>>>
>>> I followed your effort and some time ago I talked with Ed about the
>>> issue of NO_INDEX in dynamic get() and set().
>>> IIRC it is *not* specified that NO_INDEX grants read or write access
>>> to the list itself. Ed may correct me if I'm wrong.
>>> That said, I can currently not exclude that CDOObjectImpl does
>>> behave as you described in this unspecified case.
>>> Can we wait with the CDO part of the answer until Ed says something
>>> about the general contract?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
>>>
>>> Martin Taal schrieb:
>>>> Hi Eike, Ed,
>>>> I have been working with Tom on persisting CDO/EStore objects
>>>> through Teneo. Teneo needs to have access to the list instances
>>>> inside of an EStore, to ensure lazy loading etc.
>>>>
>>>> I use the following call to get to the list itself:
>>>> list = (List<?>) eStore.get((InternalEObject) eObject, eref,
>>>> EStore.NO_INDEX);
>>>>
>>>> Is it indeed correct that I can assume that passing NO_INDEX to an
>>>> EStore.get should return a List?
>>>>
>>>> Eike, with CDO, I can assume that the underlying (delegated list)
>>>> will be returned?
>>>>
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	[CDO] Important changes in HEAD
Next Topic:	Re: Teneo map references in one table

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 16:23:49 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter