Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO 0.8.0] EMap
[CDO 0.8.0] EMap [message #122818] Thu, 22 May 2008 02:53 Go to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Eike and Ed (Ed, you are more than welcome to add anything to this
thread),

the current implementation of Emap is using a hashmap. Unfortunately, to use
a hashmap we need to load all the elements of the collection. This kill the
point of proxying objects (when we are using EStore). We have cases where a
collection reach millions of objects.... I don`t want to load all of them.

I tought that an implementation using TreeMap would be better (It is an
ordered collection). In this case, I can do dichotomic search... so I will
not load all of them!
Do you think it make sense ?

The other solution I can think of its to catch the lookup and always go to
the server to lookup objects. In the server side , IStoreReader will need to
provide some functionnality to handle this (lookup(CDOFeature, Object key)
return index).

Maybe have both?!?!?!?

Do you have others ideas to solve that kind of problem ?

Thank you

Simon
Re: [CDO 0.8.0] EMap [message #122821 is a reply to message #122818] Thu, 22 May 2008 05:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon,

Conceptually I think both approaches can be useful and I know a third
one which is like a combination of the existing HashMap based
implementation and your remote lookup. We could first look into the
HashMap and do the remote lookup (plus caching in the map) only if the
key is not present. With all three apporaches we'd have to evaluate how
the other EMap API (other than lookup) fits into the approach.

Btw. I never used an EMap but I know that EMap extends EList and I
thought EMap is implemented by subclassing an EList implementation plus
linear scanning for the lookup. Ok, I just verified that my last
assumption was wrong (does it apply to EFeatureMaps?). BasicEMap is a
subclass of java.lang.Object but delegates Entry storage to an EList
which uses a BasicEList[] (is it clever to have both delegations in one
EMap implementation, how to implement a different delegateEList without
the existing entryData?).

From a CDO client point of view I wonder how an EStore "gets a sense"
for an EMap typed attribute? I can't find the lookup API in EStore.

Cheers
/Eike


Simon McDuff schrieb:
> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
> thread),
>
> the current implementation of Emap is using a hashmap. Unfortunately, to use
> a hashmap we need to load all the elements of the collection. This kill the
> point of proxying objects (when we are using EStore). We have cases where a
> collection reach millions of objects.... I don`t want to load all of them.
>
> I tought that an implementation using TreeMap would be better (It is an
> ordered collection). In this case, I can do dichotomic search... so I will
> not load all of them!
> Do you think it make sense ?
>
> The other solution I can think of its to catch the lookup and always go to
> the server to lookup objects. In the server side , IStoreReader will need to
> provide some functionnality to handle this (lookup(CDOFeature, Object key)
> return index).
>
> Maybe have both?!?!?!?
>
> Do you have others ideas to solve that kind of problem ?
>
> Thank you
>
> Simon
>
>
>
Re: [CDO 0.8.0] EMap [message #122851 is a reply to message #122821] Thu, 22 May 2008 11:48 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
EMAP is a list of a class that only have a key and a value.

EMap always add at the end of the list.

The estore only knows index of a list!!

"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #122855 is a reply to message #122851] Thu, 22 May 2008 11:52 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon McDuff schrieb:
> EMAP is a list of a class that only have a key and a value.
>
> EMap always add at the end of the list.
>
> The estore only knows index of a list!!
>
That's known. But what about the important part: EStore?

> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g12v36$ik7$1@build.eclipse.org...
>
>> Simon,
>>
>> Conceptually I think both approaches can be useful and I know a third one
>> which is like a combination of the existing HashMap based implementation
>> and your remote lookup. We could first look into the HashMap and do the
>> remote lookup (plus caching in the map) only if the key is not present.
>> With all three apporaches we'd have to evaluate how the other EMap API
>> (other than lookup) fits into the approach.
>>
>> Btw. I never used an EMap but I know that EMap extends EList and I thought
>> EMap is implemented by subclassing an EList implementation plus linear
>> scanning for the lookup. Ok, I just verified that my last assumption was
>> wrong (does it apply to EFeatureMaps?). BasicEMap is a subclass of
>> java.lang.Object but delegates Entry storage to an EList which uses a
>> BasicEList[] (is it clever to have both delegations in one EMap
>> implementation, how to implement a different delegateEList without the
>> existing entryData?).
>>
>> From a CDO client point of view I wonder how an EStore "gets a sense" for
>> an EMap typed attribute? I can't find the lookup API in EStore.
>>
>> Cheers
>> /Eike
>>
>>
>> Simon McDuff schrieb:
>>
>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
>>> thread),
>>>
>>> the current implementation of Emap is using a hashmap. Unfortunately, to
>>> use a hashmap we need to load all the elements of the collection. This
>>> kill the point of proxying objects (when we are using EStore). We have
>>> cases where a collection reach millions of objects.... I don`t want to
>>> load all of them.
>>>
>>> I tought that an implementation using TreeMap would be better (It is an
>>> ordered collection). In this case, I can do dichotomic search... so I
>>> will not load all of them!
>>> Do you think it make sense ?
>>>
>>> The other solution I can think of its to catch the lookup and always go
>>> to the server to lookup objects. In the server side , IStoreReader will
>>> need to provide some functionnality to handle this (lookup(CDOFeature,
>>> Object key) return index).
>>>
>>> Maybe have both?!?!?!?
>>>
>>> Do you have others ideas to solve that kind of problem ?
>>>
>>> Thank you
>>>
>>> Simon
>>>
>>>
>>>
>
>
>
Re: [CDO 0.8.0] EMap [message #122870 is a reply to message #122855] Thu, 22 May 2008 14:46 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
(I`m just describing the current implementation)

But by knowing that,
Estore doesn`t to know anything about EMap. Doesn`t need to since
EBasicMap will only sent the following message to the Estore (not directly).
Lookup calls are kept internally, so the Estore never know about it.. since
EBasicMap built is hashmap at the initialization.

Object get(InternalEObject object, EStructuralFeature feature, int index);

Object set(InternalEObject object, EStructuralFeature feature, int index,
Object value);

int size(InternalEObject object, EStructuralFeature feature);

etc....






"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #122874 is a reply to message #122870] Thu, 22 May 2008 16:02 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon McDuff schrieb:
> (I`m just describing the current implementation)
>
> But by knowing that,
> Estore doesn`t to know anything about EMap. Doesn`t need to since
> EBasicMap will only sent the following message to the Estore (not directly).
> Lookup calls are kept internally, so the Estore never know about it.. since
> EBasicMap built is hashmap at the initialization.
>
> Object get(InternalEObject object, EStructuralFeature feature, int index);
>
> Object set(InternalEObject object, EStructuralFeature feature, int index,
> Object value);
>
> int size(InternalEObject object, EStructuralFeature feature);
>
> etc....
>
Then I wonder how a (CDO-based) solution might look like that solves the
problem you initially described?


Cheers
/Eike

>
> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g13mpg$1pa$4@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> EMAP is a list of a class that only have a key and a value.
>>>
>>> EMap always add at the end of the list.
>>>
>>> The estore only knows index of a list!!
>>>
>>>
>> That's known. But what about the important part: EStore?
>>
>>
>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>> g12v36$ik7$1@build.eclipse.org...
>>>
>>>
>>>> Simon,
>>>>
>>>> Conceptually I think both approaches can be useful and I know a third
>>>> one which is like a combination of the existing HashMap based
>>>> implementation and your remote lookup. We could first look into the
>>>> HashMap and do the remote lookup (plus caching in the map) only if the
>>>> key is not present. With all three apporaches we'd have to evaluate how
>>>> the other EMap API (other than lookup) fits into the approach.
>>>>
>>>> Btw. I never used an EMap but I know that EMap extends EList and I
>>>> thought EMap is implemented by subclassing an EList implementation plus
>>>> linear scanning for the lookup. Ok, I just verified that my last
>>>> assumption was wrong (does it apply to EFeatureMaps?). BasicEMap is a
>>>> subclass of java.lang.Object but delegates Entry storage to an EList
>>>> which uses a BasicEList[] (is it clever to have both delegations in one
>>>> EMap implementation, how to implement a different delegateEList without
>>>> the existing entryData?).
>>>>
>>>> From a CDO client point of view I wonder how an EStore "gets a sense"
>>>> for an EMap typed attribute? I can't find the lookup API in EStore.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
>>>>> thread),
>>>>>
>>>>> the current implementation of Emap is using a hashmap. Unfortunately,
>>>>> to use a hashmap we need to load all the elements of the collection.
>>>>> This kill the point of proxying objects (when we are using EStore). We
>>>>> have cases where a collection reach millions of objects.... I don`t
>>>>> want to load all of them.
>>>>>
>>>>> I tought that an implementation using TreeMap would be better (It is an
>>>>> ordered collection). In this case, I can do dichotomic search... so I
>>>>> will not load all of them!
>>>>> Do you think it make sense ?
>>>>>
>>>>> The other solution I can think of its to catch the lookup and always go
>>>>> to the server to lookup objects. In the server side , IStoreReader will
>>>>> need to provide some functionnality to handle this (lookup(CDOFeature,
>>>>> Object key) return index).
>>>>>
>>>>> Maybe have both?!?!?!?
>>>>>
>>>>> Do you have others ideas to solve that kind of problem ?
>>>>>
>>>>> Thank you
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: [CDO 0.8.0] EMap [message #122878 is a reply to message #122874] Thu, 22 May 2008 16:38 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
OK.. basically to provide our own implementation of EMap !!

So we can handle any cases!!




"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #122882 is a reply to message #122878] Thu, 22 May 2008 16:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Simon,

I suggest that you enter a feature request to discuss the details there.
Please describe where you intend to create instances of such a new EMap.

Cheers
/Eike


Simon McDuff schrieb:
> OK.. basically to provide our own implementation of EMap !!
>
> So we can handle any cases!!
>
>
>
>
> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g145fg$mtc$1@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> (I`m just describing the current implementation)
>>>
>>> But by knowing that,
>>> Estore doesn`t to know anything about EMap. Doesn`t need to since
>>> EBasicMap will only sent the following message to the Estore (not
>>> directly). Lookup calls are kept internally, so the Estore never know
>>> about it.. since EBasicMap built is hashmap at the initialization.
>>>
>>> Object get(InternalEObject object, EStructuralFeature feature, int
>>> index);
>>>
>>> Object set(InternalEObject object, EStructuralFeature feature, int index,
>>> Object value);
>>>
>>> int size(InternalEObject object, EStructuralFeature feature);
>>>
>>> etc....
>>>
>>>
>> Then I wonder how a (CDO-based) solution might look like that solves the
>> problem you initially described?
>>
>>
>> Cheers
>> /Eike
>>
>>
>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>> g13mpg$1pa$4@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> EMAP is a list of a class that only have a key and a value.
>>>>>
>>>>> EMap always add at the end of the list.
>>>>>
>>>>> The estore only knows index of a list!!
>>>>>
>>>>>
>>>>>
>>>> That's known. But what about the important part: EStore?
>>>>
>>>>
>>>>
>>>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>>>> g12v36$ik7$1@build.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>> Simon,
>>>>>>
>>>>>> Conceptually I think both approaches can be useful and I know a third
>>>>>> one which is like a combination of the existing HashMap based
>>>>>> implementation and your remote lookup. We could first look into the
>>>>>> HashMap and do the remote lookup (plus caching in the map) only if the
>>>>>> key is not present. With all three apporaches we'd have to evaluate
>>>>>> how the other EMap API (other than lookup) fits into the approach.
>>>>>>
>>>>>> Btw. I never used an EMap but I know that EMap extends EList and I
>>>>>> thought EMap is implemented by subclassing an EList implementation
>>>>>> plus linear scanning for the lookup. Ok, I just verified that my last
>>>>>> assumption was wrong (does it apply to EFeatureMaps?). BasicEMap is a
>>>>>> subclass of java.lang.Object but delegates Entry storage to an EList
>>>>>> which uses a BasicEList[] (is it clever to have both delegations in
>>>>>> one EMap implementation, how to implement a different delegateEList
>>>>>> without the existing entryData?).
>>>>>>
>>>>>> From a CDO client point of view I wonder how an EStore "gets a sense"
>>>>>> for an EMap typed attribute? I can't find the lookup API in EStore.
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Simon McDuff schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
>>>>>>> thread),
>>>>>>>
>>>>>>> the current implementation of Emap is using a hashmap. Unfortunately,
>>>>>>> to use a hashmap we need to load all the elements of the collection.
>>>>>>> This kill the point of proxying objects (when we are using EStore).
>>>>>>> We have cases where a collection reach millions of objects.... I
>>>>>>> don`t want to load all of them.
>>>>>>>
>>>>>>> I tought that an implementation using TreeMap would be better (It is
>>>>>>> an ordered collection). In this case, I can do dichotomic search...
>>>>>>> so I will not load all of them!
>>>>>>> Do you think it make sense ?
>>>>>>>
>>>>>>> The other solution I can think of its to catch the lookup and always
>>>>>>> go to the server to lookup objects. In the server side , IStoreReader
>>>>>>> will need to provide some functionnality to handle this
>>>>>>> (lookup(CDOFeature, Object key) return index).
>>>>>>>
>>>>>>> Maybe have both?!?!?!?
>>>>>>>
>>>>>>> Do you have others ideas to solve that kind of problem ?
>>>>>>>
>>>>>>> Thank you
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>
>
>
Re: [CDO 0.8.0] EMap [message #122886 is a reply to message #122882] Thu, 22 May 2008 17:11 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Done
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233495

Do you know if version 0.9 available soon in bugzilla ? This will not be in
0.8.0... I`m pretty sure!


"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #122890 is a reply to message #122886] Thu, 22 May 2008 17:25 Go to previous message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon McDuff schrieb:
> Done
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233495
>
> Do you know if version 0.9 available soon in bugzilla ? This will not be in
> 0.8.0... I`m pretty sure!
>
This should be the version that we found a bug in, not the target
version ;-)
We stay with 0.8 for the time being...
However I cc'ed Nick...

Cheers
/Eike


>
> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g147kt$mtc$2@build.eclipse.org...
>
>> Hi Simon,
>>
>> I suggest that you enter a feature request to discuss the details there.
>> Please describe where you intend to create instances of such a new EMap.
>>
>> Cheers
>> /Eike
>>
>>
>> Simon McDuff schrieb:
>>
>>> OK.. basically to provide our own implementation of EMap !!
>>>
>>> So we can handle any cases!!
>>>
>>>
>>>
>>>
>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>> g145fg$mtc$1@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> (I`m just describing the current implementation)
>>>>>
>>>>> But by knowing that,
>>>>> Estore doesn`t to know anything about EMap. Doesn`t need to since
>>>>> EBasicMap will only sent the following message to the Estore (not
>>>>> directly). Lookup calls are kept internally, so the Estore never know
>>>>> about it.. since EBasicMap built is hashmap at the initialization.
>>>>>
>>>>> Object get(InternalEObject object, EStructuralFeature feature, int
>>>>> index);
>>>>>
>>>>> Object set(InternalEObject object, EStructuralFeature feature, int
>>>>> index, Object value);
>>>>>
>>>>> int size(InternalEObject object, EStructuralFeature feature);
>>>>>
>>>>> etc....
>>>>>
>>>>>
>>>>>
>>>> Then I wonder how a (CDO-based) solution might look like that solves the
>>>> problem you initially described?
>>>>
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>>
>>>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>>>> g13mpg$1pa$4@build.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>> Simon McDuff schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> EMAP is a list of a class that only have a key and a value.
>>>>>>>
>>>>>>> EMap always add at the end of the list.
>>>>>>>
>>>>>>> The estore only knows index of a list!!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> That's known. But what about the important part: EStore?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>>>>>> g12v36$ik7$1@build.eclipse.org...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Simon,
>>>>>>>>
>>>>>>>> Conceptually I think both approaches can be useful and I know a
>>>>>>>> third one which is like a combination of the existing HashMap based
>>>>>>>> implementation and your remote lookup. We could first look into the
>>>>>>>> HashMap and do the remote lookup (plus caching in the map) only if
>>>>>>>> the key is not present. With all three apporaches we'd have to
>>>>>>>> evaluate how the other EMap API (other than lookup) fits into the
>>>>>>>> approach.
>>>>>>>>
>>>>>>>> Btw. I never used an EMap but I know that EMap extends EList and I
>>>>>>>> thought EMap is implemented by subclassing an EList implementation
>>>>>>>> plus linear scanning for the lookup. Ok, I just verified that my
>>>>>>>> last assumption was wrong (does it apply to EFeatureMaps?).
>>>>>>>> BasicEMap is a subclass of java.lang.Object but delegates Entry
>>>>>>>> storage to an EList which uses a BasicEList[] (is it clever to have
>>>>>>>> both delegations in one EMap implementation, how to implement a
>>>>>>>> different delegateEList without the existing entryData?).
>>>>>>>>
>>>>>>>> From a CDO client point of view I wonder how an EStore "gets a
>>>>>>>> sense" for an EMap typed attribute? I can't find the lookup API in
>>>>>>>> EStore.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>
>>>>>>>> Simon McDuff schrieb:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to
>>>>>>>>> this thread),
>>>>>>>>>
>>>>>>>>> the current implementation of Emap is using a hashmap.
>>>>>>>>> Unfortunately, to use a hashmap we need to load all the elements of
>>>>>>>>> the collection. This kill the point of proxying objects (when we
>>>>>>>>> are using EStore). We have cases where a collection reach millions
>>>>>>>>> of objects.... I don`t want to load all of them.
>>>>>>>>>
>>>>>>>>> I tought that an implementation using TreeMap would be better (It
>>>>>>>>> is an ordered collection). In this case, I can do dichotomic
>>>>>>>>> search... so I will not load all of them!
>>>>>>>>> Do you think it make sense ?
>>>>>>>>>
>>>>>>>>> The other solution I can think of its to catch the lookup and
>>>>>>>>> always go to the server to lookup objects. In the server side ,
>>>>>>>>> IStoreReader will need to provide some functionnality to handle
>>>>>>>>> this (lookup(CDOFeature, Object key) return index).
>>>>>>>>>
>>>>>>>>> Maybe have both?!?!?!?
>>>>>>>>>
>>>>>>>>> Do you have others ideas to solve that kind of problem ?
>>>>>>>>>
>>>>>>>>> Thank you
>>>>>>>>>
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
>>>
>
>
>
Re: [CDO 0.8.0] EMap [message #618117 is a reply to message #122818] Thu, 22 May 2008 05:07 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon,

Conceptually I think both approaches can be useful and I know a third
one which is like a combination of the existing HashMap based
implementation and your remote lookup. We could first look into the
HashMap and do the remote lookup (plus caching in the map) only if the
key is not present. With all three apporaches we'd have to evaluate how
the other EMap API (other than lookup) fits into the approach.

Btw. I never used an EMap but I know that EMap extends EList and I
thought EMap is implemented by subclassing an EList implementation plus
linear scanning for the lookup. Ok, I just verified that my last
assumption was wrong (does it apply to EFeatureMaps?). BasicEMap is a
subclass of java.lang.Object but delegates Entry storage to an EList
which uses a BasicEList[] (is it clever to have both delegations in one
EMap implementation, how to implement a different delegateEList without
the existing entryData?).

From a CDO client point of view I wonder how an EStore "gets a sense"
for an EMap typed attribute? I can't find the lookup API in EStore.

Cheers
/Eike


Simon McDuff schrieb:
> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
> thread),
>
> the current implementation of Emap is using a hashmap. Unfortunately, to use
> a hashmap we need to load all the elements of the collection. This kill the
> point of proxying objects (when we are using EStore). We have cases where a
> collection reach millions of objects.... I don`t want to load all of them.
>
> I tought that an implementation using TreeMap would be better (It is an
> ordered collection). In this case, I can do dichotomic search... so I will
> not load all of them!
> Do you think it make sense ?
>
> The other solution I can think of its to catch the lookup and always go to
> the server to lookup objects. In the server side , IStoreReader will need to
> provide some functionnality to handle this (lookup(CDOFeature, Object key)
> return index).
>
> Maybe have both?!?!?!?
>
> Do you have others ideas to solve that kind of problem ?
>
> Thank you
>
> Simon
>
>
>


Re: [CDO 0.8.0] EMap [message #618129 is a reply to message #122821] Thu, 22 May 2008 11:48 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
EMAP is a list of a class that only have a key and a value.

EMap always add at the end of the list.

The estore only knows index of a list!!

"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #618131 is a reply to message #122851] Thu, 22 May 2008 11:52 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> EMAP is a list of a class that only have a key and a value.
>
> EMap always add at the end of the list.
>
> The estore only knows index of a list!!
>
That's known. But what about the important part: EStore?

> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g12v36$ik7$1@build.eclipse.org...
>
>> Simon,
>>
>> Conceptually I think both approaches can be useful and I know a third one
>> which is like a combination of the existing HashMap based implementation
>> and your remote lookup. We could first look into the HashMap and do the
>> remote lookup (plus caching in the map) only if the key is not present.
>> With all three apporaches we'd have to evaluate how the other EMap API
>> (other than lookup) fits into the approach.
>>
>> Btw. I never used an EMap but I know that EMap extends EList and I thought
>> EMap is implemented by subclassing an EList implementation plus linear
>> scanning for the lookup. Ok, I just verified that my last assumption was
>> wrong (does it apply to EFeatureMaps?). BasicEMap is a subclass of
>> java.lang.Object but delegates Entry storage to an EList which uses a
>> BasicEList[] (is it clever to have both delegations in one EMap
>> implementation, how to implement a different delegateEList without the
>> existing entryData?).
>>
>> From a CDO client point of view I wonder how an EStore "gets a sense" for
>> an EMap typed attribute? I can't find the lookup API in EStore.
>>
>> Cheers
>> /Eike
>>
>>
>> Simon McDuff schrieb:
>>
>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
>>> thread),
>>>
>>> the current implementation of Emap is using a hashmap. Unfortunately, to
>>> use a hashmap we need to load all the elements of the collection. This
>>> kill the point of proxying objects (when we are using EStore). We have
>>> cases where a collection reach millions of objects.... I don`t want to
>>> load all of them.
>>>
>>> I tought that an implementation using TreeMap would be better (It is an
>>> ordered collection). In this case, I can do dichotomic search... so I
>>> will not load all of them!
>>> Do you think it make sense ?
>>>
>>> The other solution I can think of its to catch the lookup and always go
>>> to the server to lookup objects. In the server side , IStoreReader will
>>> need to provide some functionnality to handle this (lookup(CDOFeature,
>>> Object key) return index).
>>>
>>> Maybe have both?!?!?!?
>>>
>>> Do you have others ideas to solve that kind of problem ?
>>>
>>> Thank you
>>>
>>> Simon
>>>
>>>
>>>
>
>
>


Re: [CDO 0.8.0] EMap [message #618136 is a reply to message #122855] Thu, 22 May 2008 14:46 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
(I`m just describing the current implementation)

But by knowing that,
Estore doesn`t to know anything about EMap. Doesn`t need to since
EBasicMap will only sent the following message to the Estore (not directly).
Lookup calls are kept internally, so the Estore never know about it.. since
EBasicMap built is hashmap at the initialization.

Object get(InternalEObject object, EStructuralFeature feature, int index);

Object set(InternalEObject object, EStructuralFeature feature, int index,
Object value);

int size(InternalEObject object, EStructuralFeature feature);

etc....






"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #618138 is a reply to message #122870] Thu, 22 May 2008 16:02 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> (I`m just describing the current implementation)
>
> But by knowing that,
> Estore doesn`t to know anything about EMap. Doesn`t need to since
> EBasicMap will only sent the following message to the Estore (not directly).
> Lookup calls are kept internally, so the Estore never know about it.. since
> EBasicMap built is hashmap at the initialization.
>
> Object get(InternalEObject object, EStructuralFeature feature, int index);
>
> Object set(InternalEObject object, EStructuralFeature feature, int index,
> Object value);
>
> int size(InternalEObject object, EStructuralFeature feature);
>
> etc....
>
Then I wonder how a (CDO-based) solution might look like that solves the
problem you initially described?


Cheers
/Eike

>
> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g13mpg$1pa$4@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> EMAP is a list of a class that only have a key and a value.
>>>
>>> EMap always add at the end of the list.
>>>
>>> The estore only knows index of a list!!
>>>
>>>
>> That's known. But what about the important part: EStore?
>>
>>
>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>> g12v36$ik7$1@build.eclipse.org...
>>>
>>>
>>>> Simon,
>>>>
>>>> Conceptually I think both approaches can be useful and I know a third
>>>> one which is like a combination of the existing HashMap based
>>>> implementation and your remote lookup. We could first look into the
>>>> HashMap and do the remote lookup (plus caching in the map) only if the
>>>> key is not present. With all three apporaches we'd have to evaluate how
>>>> the other EMap API (other than lookup) fits into the approach.
>>>>
>>>> Btw. I never used an EMap but I know that EMap extends EList and I
>>>> thought EMap is implemented by subclassing an EList implementation plus
>>>> linear scanning for the lookup. Ok, I just verified that my last
>>>> assumption was wrong (does it apply to EFeatureMaps?). BasicEMap is a
>>>> subclass of java.lang.Object but delegates Entry storage to an EList
>>>> which uses a BasicEList[] (is it clever to have both delegations in one
>>>> EMap implementation, how to implement a different delegateEList without
>>>> the existing entryData?).
>>>>
>>>> From a CDO client point of view I wonder how an EStore "gets a sense"
>>>> for an EMap typed attribute? I can't find the lookup API in EStore.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
>>>>> thread),
>>>>>
>>>>> the current implementation of Emap is using a hashmap. Unfortunately,
>>>>> to use a hashmap we need to load all the elements of the collection.
>>>>> This kill the point of proxying objects (when we are using EStore). We
>>>>> have cases where a collection reach millions of objects.... I don`t
>>>>> want to load all of them.
>>>>>
>>>>> I tought that an implementation using TreeMap would be better (It is an
>>>>> ordered collection). In this case, I can do dichotomic search... so I
>>>>> will not load all of them!
>>>>> Do you think it make sense ?
>>>>>
>>>>> The other solution I can think of its to catch the lookup and always go
>>>>> to the server to lookup objects. In the server side , IStoreReader will
>>>>> need to provide some functionnality to handle this (lookup(CDOFeature,
>>>>> Object key) return index).
>>>>>
>>>>> Maybe have both?!?!?!?
>>>>>
>>>>> Do you have others ideas to solve that kind of problem ?
>>>>>
>>>>> Thank you
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>


Re: [CDO 0.8.0] EMap [message #618140 is a reply to message #122874] Thu, 22 May 2008 16:38 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
OK.. basically to provide our own implementation of EMap !!

So we can handle any cases!!




"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #618142 is a reply to message #122878] Thu, 22 May 2008 16:39 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Simon,

I suggest that you enter a feature request to discuss the details there.
Please describe where you intend to create instances of such a new EMap.

Cheers
/Eike


Simon McDuff schrieb:
> OK.. basically to provide our own implementation of EMap !!
>
> So we can handle any cases!!
>
>
>
>
> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g145fg$mtc$1@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> (I`m just describing the current implementation)
>>>
>>> But by knowing that,
>>> Estore doesn`t to know anything about EMap. Doesn`t need to since
>>> EBasicMap will only sent the following message to the Estore (not
>>> directly). Lookup calls are kept internally, so the Estore never know
>>> about it.. since EBasicMap built is hashmap at the initialization.
>>>
>>> Object get(InternalEObject object, EStructuralFeature feature, int
>>> index);
>>>
>>> Object set(InternalEObject object, EStructuralFeature feature, int index,
>>> Object value);
>>>
>>> int size(InternalEObject object, EStructuralFeature feature);
>>>
>>> etc....
>>>
>>>
>> Then I wonder how a (CDO-based) solution might look like that solves the
>> problem you initially described?
>>
>>
>> Cheers
>> /Eike
>>
>>
>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>> g13mpg$1pa$4@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> EMAP is a list of a class that only have a key and a value.
>>>>>
>>>>> EMap always add at the end of the list.
>>>>>
>>>>> The estore only knows index of a list!!
>>>>>
>>>>>
>>>>>
>>>> That's known. But what about the important part: EStore?
>>>>
>>>>
>>>>
>>>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>>>> g12v36$ik7$1@build.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>> Simon,
>>>>>>
>>>>>> Conceptually I think both approaches can be useful and I know a third
>>>>>> one which is like a combination of the existing HashMap based
>>>>>> implementation and your remote lookup. We could first look into the
>>>>>> HashMap and do the remote lookup (plus caching in the map) only if the
>>>>>> key is not present. With all three apporaches we'd have to evaluate
>>>>>> how the other EMap API (other than lookup) fits into the approach.
>>>>>>
>>>>>> Btw. I never used an EMap but I know that EMap extends EList and I
>>>>>> thought EMap is implemented by subclassing an EList implementation
>>>>>> plus linear scanning for the lookup. Ok, I just verified that my last
>>>>>> assumption was wrong (does it apply to EFeatureMaps?). BasicEMap is a
>>>>>> subclass of java.lang.Object but delegates Entry storage to an EList
>>>>>> which uses a BasicEList[] (is it clever to have both delegations in
>>>>>> one EMap implementation, how to implement a different delegateEList
>>>>>> without the existing entryData?).
>>>>>>
>>>>>> From a CDO client point of view I wonder how an EStore "gets a sense"
>>>>>> for an EMap typed attribute? I can't find the lookup API in EStore.
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Simon McDuff schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to this
>>>>>>> thread),
>>>>>>>
>>>>>>> the current implementation of Emap is using a hashmap. Unfortunately,
>>>>>>> to use a hashmap we need to load all the elements of the collection.
>>>>>>> This kill the point of proxying objects (when we are using EStore).
>>>>>>> We have cases where a collection reach millions of objects.... I
>>>>>>> don`t want to load all of them.
>>>>>>>
>>>>>>> I tought that an implementation using TreeMap would be better (It is
>>>>>>> an ordered collection). In this case, I can do dichotomic search...
>>>>>>> so I will not load all of them!
>>>>>>> Do you think it make sense ?
>>>>>>>
>>>>>>> The other solution I can think of its to catch the lookup and always
>>>>>>> go to the server to lookup objects. In the server side , IStoreReader
>>>>>>> will need to provide some functionnality to handle this
>>>>>>> (lookup(CDOFeature, Object key) return index).
>>>>>>>
>>>>>>> Maybe have both?!?!?!?
>>>>>>>
>>>>>>> Do you have others ideas to solve that kind of problem ?
>>>>>>>
>>>>>>> Thank you
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>
>
>


Re: [CDO 0.8.0] EMap [message #618144 is a reply to message #122882] Thu, 22 May 2008 17:11 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Done
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233495

Do you know if version 0.9 available soon in bugzilla ? This will not be in
0.8.0... I`m pretty sure!


"Eike Stepper" <stepper@sympedia.de> a
Re: [CDO 0.8.0] EMap [message #618146 is a reply to message #122886] Thu, 22 May 2008 17:25 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> Done
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233495
>
> Do you know if version 0.9 available soon in bugzilla ? This will not be in
> 0.8.0... I`m pretty sure!
>
This should be the version that we found a bug in, not the target
version ;-)
We stay with 0.8 for the time being...
However I cc'ed Nick...

Cheers
/Eike


>
> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
> g147kt$mtc$2@build.eclipse.org...
>
>> Hi Simon,
>>
>> I suggest that you enter a feature request to discuss the details there.
>> Please describe where you intend to create instances of such a new EMap.
>>
>> Cheers
>> /Eike
>>
>>
>> Simon McDuff schrieb:
>>
>>> OK.. basically to provide our own implementation of EMap !!
>>>
>>> So we can handle any cases!!
>>>
>>>
>>>
>>>
>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>> g145fg$mtc$1@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> (I`m just describing the current implementation)
>>>>>
>>>>> But by knowing that,
>>>>> Estore doesn`t to know anything about EMap. Doesn`t need to since
>>>>> EBasicMap will only sent the following message to the Estore (not
>>>>> directly). Lookup calls are kept internally, so the Estore never know
>>>>> about it.. since EBasicMap built is hashmap at the initialization.
>>>>>
>>>>> Object get(InternalEObject object, EStructuralFeature feature, int
>>>>> index);
>>>>>
>>>>> Object set(InternalEObject object, EStructuralFeature feature, int
>>>>> index, Object value);
>>>>>
>>>>> int size(InternalEObject object, EStructuralFeature feature);
>>>>>
>>>>> etc....
>>>>>
>>>>>
>>>>>
>>>> Then I wonder how a (CDO-based) solution might look like that solves the
>>>> problem you initially described?
>>>>
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>>
>>>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>>>> g13mpg$1pa$4@build.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>> Simon McDuff schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> EMAP is a list of a class that only have a key and a value.
>>>>>>>
>>>>>>> EMap always add at the end of the list.
>>>>>>>
>>>>>>> The estore only knows index of a list!!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> That's known. But what about the important part: EStore?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> "Eike Stepper" <stepper@sympedia.de> a écrit dans le message de news:
>>>>>>> g12v36$ik7$1@build.eclipse.org...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Simon,
>>>>>>>>
>>>>>>>> Conceptually I think both approaches can be useful and I know a
>>>>>>>> third one which is like a combination of the existing HashMap based
>>>>>>>> implementation and your remote lookup. We could first look into the
>>>>>>>> HashMap and do the remote lookup (plus caching in the map) only if
>>>>>>>> the key is not present. With all three apporaches we'd have to
>>>>>>>> evaluate how the other EMap API (other than lookup) fits into the
>>>>>>>> approach.
>>>>>>>>
>>>>>>>> Btw. I never used an EMap but I know that EMap extends EList and I
>>>>>>>> thought EMap is implemented by subclassing an EList implementation
>>>>>>>> plus linear scanning for the lookup. Ok, I just verified that my
>>>>>>>> last assumption was wrong (does it apply to EFeatureMaps?).
>>>>>>>> BasicEMap is a subclass of java.lang.Object but delegates Entry
>>>>>>>> storage to an EList which uses a BasicEList[] (is it clever to have
>>>>>>>> both delegations in one EMap implementation, how to implement a
>>>>>>>> different delegateEList without the existing entryData?).
>>>>>>>>
>>>>>>>> From a CDO client point of view I wonder how an EStore "gets a
>>>>>>>> sense" for an EMap typed attribute? I can't find the lookup API in
>>>>>>>> EStore.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>
>>>>>>>> Simon McDuff schrieb:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Eike and Ed (Ed, you are more than welcome to add anything to
>>>>>>>>> this thread),
>>>>>>>>>
>>>>>>>>> the current implementation of Emap is using a hashmap.
>>>>>>>>> Unfortunately, to use a hashmap we need to load all the elements of
>>>>>>>>> the collection. This kill the point of proxying objects (when we
>>>>>>>>> are using EStore). We have cases where a collection reach millions
>>>>>>>>> of objects.... I don`t want to load all of them.
>>>>>>>>>
>>>>>>>>> I tought that an implementation using TreeMap would be better (It
>>>>>>>>> is an ordered collection). In this case, I can do dichotomic
>>>>>>>>> search... so I will not load all of them!
>>>>>>>>> Do you think it make sense ?
>>>>>>>>>
>>>>>>>>> The other solution I can think of its to catch the lookup and
>>>>>>>>> always go to the server to lookup objects. In the server side ,
>>>>>>>>> IStoreReader will need to provide some functionnality to handle
>>>>>>>>> this (lookup(CDOFeature, Object key) return index).
>>>>>>>>>
>>>>>>>>> Maybe have both?!?!?!?
>>>>>>>>>
>>>>>>>>> Do you have others ideas to solve that kind of problem ?
>>>>>>>>>
>>>>>>>>> Thank you
>>>>>>>>>
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
>>>
>
>
>


Previous Topic:[Teneo] Unexpected repeated column error
Next Topic:[Teneo] Hiberante and Hbxml resource
Goto Forum:
  


Current Time: Wed Apr 08 07:50:43 GMT 2020

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

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

Back to the top