Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Swapping EStores
Swapping EStores [message #411314] Mon, 23 July 2007 07:39 Go to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5574
Registered: July 2009
Senior Member
Hi,

Maybe I asked a similar question before but I couldn't find a thread
anymore.

EStoreEObjectImpl has got an eSetStore() method (even InternalEObject)
which connects the instance to or disconnects it from an EStore.
Unfortunately it is only usable *before* state has been set to the instance.
After lists habe been created lazily it is not possible anymore to
change the store because the it is stored in member fields of the lists.
There is even not a setter to change the list store after construction ;-(
With this implementation I'll have to iterate over the eSettings of the
EStoreEObjectImpl and reflectively change the eStore field.
Maybe I can overwrite createList() and createFeatureMap() to provide
collections with a setter method that can be used after explicit
downcasting.

I'm not sure if at all there is a use case for different stores in
EStoreEObjectImpl and its internal collections.
It would at least be much nicer if abstract superclasses of these
collections were provided that have an abstract eStore() method that I
could implement to return the store of the owner.

What do you think?

Cheers
/Eike
Re: Swapping EStores [message #411315 is a reply to message #411314] Mon, 23 July 2007 07:50 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5574
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020903030208020807080402
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Oh no:

public static class EStoreFeatureMap extends DelegatingFeatureMap
{
protected *final *InternalEObject.EStore store;
...

Hmm, whether reflection can trick this one???




Eike Stepper schrieb:
> Hi,
>
> Maybe I asked a similar question before but I couldn't find a thread
> anymore.
>
> EStoreEObjectImpl has got an eSetStore() method (even InternalEObject)
> which connects the instance to or disconnects it from an EStore.
> Unfortunately it is only usable *before* state has been set to the
> instance.
> After lists habe been created lazily it is not possible anymore to
> change the store because the it is stored in member fields of the lists.
> There is even not a setter to change the list store after construction
> ;-(
> With this implementation I'll have to iterate over the eSettings of
> the EStoreEObjectImpl and reflectively change the eStore field.
> Maybe I can overwrite createList() and createFeatureMap() to provide
> collections with a setter method that can be used after explicit
> downcasting.
>
> I'm not sure if at all there is a use case for different stores in
> EStoreEObjectImpl and its internal collections.
> It would at least be much nicer if abstract superclasses of these
> collections were provided that have an abstract eStore() method that I
> could implement to return the store of the owner.
>
> What do you think?
>
> Cheers
> /Eike
>

--------------020903030208020807080402
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Oh no:<br>
<br>
Re: Swapping EStores [message #411319 is a reply to message #411314] Mon, 23 July 2007 12:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26215
Registered: July 2009
Senior Member
Eike,

Perhaps base classes that simply fetch the store from the owner would be
a good idea. I suppose it's also possible to use a store than can
itself be redirected to talk to different data sources.


Eike Stepper wrote:
> Hi,
>
> Maybe I asked a similar question before but I couldn't find a thread
> anymore.
>
> EStoreEObjectImpl has got an eSetStore() method (even InternalEObject)
> which connects the instance to or disconnects it from an EStore.
> Unfortunately it is only usable *before* state has been set to the
> instance.
> After lists habe been created lazily it is not possible anymore to
> change the store because the it is stored in member fields of the lists.
> There is even not a setter to change the list store after construction
> ;-(
> With this implementation I'll have to iterate over the eSettings of
> the EStoreEObjectImpl and reflectively change the eStore field.
> Maybe I can overwrite createList() and createFeatureMap() to provide
> collections with a setter method that can be used after explicit
> downcasting.
>
> I'm not sure if at all there is a use case for different stores in
> EStoreEObjectImpl and its internal collections.
> It would at least be much nicer if abstract superclasses of these
> collections were provided that have an abstract eStore() method that I
> could implement to return the store of the owner.
>
> What do you think?
>
> Cheers
> /Eike
>
Re: Swapping EStores [message #411323 is a reply to message #411319] Mon, 23 July 2007 13:56 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5574
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> Perhaps base classes that simply fetch the store from the owner would
> be a good idea.
Shall I open an Enhancement request?

> I suppose it's also possible to use a store than can itself be
> redirected to talk to different data sources.
I already do something like that. My stores don't store the model values
themselves, i.e. they don't store instance specific state. But they have
some other data related that is common for certain groups of instances.

>
>
> Eike Stepper wrote:
>> Hi,
>>
>> Maybe I asked a similar question before but I couldn't find a thread
>> anymore.
>>
>> EStoreEObjectImpl has got an eSetStore() method (even
>> InternalEObject) which connects the instance to or disconnects it
>> from an EStore.
>> Unfortunately it is only usable *before* state has been set to the
>> instance.
>> After lists habe been created lazily it is not possible anymore to
>> change the store because the it is stored in member fields of the lists.
>> There is even not a setter to change the list store after
>> construction ;-(
>> With this implementation I'll have to iterate over the eSettings of
>> the EStoreEObjectImpl and reflectively change the eStore field.
>> Maybe I can overwrite createList() and createFeatureMap() to provide
>> collections with a setter method that can be used after explicit
>> downcasting.
>>
>> I'm not sure if at all there is a use case for different stores in
>> EStoreEObjectImpl and its internal collections.
>> It would at least be much nicer if abstract superclasses of these
>> collections were provided that have an abstract eStore() method that
>> I could implement to return the store of the owner.
>>
>> What do you think?
>>
>> Cheers
>> /Eike
>>
Re: Swapping EStores [message #411324 is a reply to message #411323] Mon, 23 July 2007 14:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26215
Registered: July 2009
Senior Member
Eike,

Yes, please open an enhancement request.


Eike Stepper wrote:
> Ed Merks schrieb:
>> Eike,
>>
>> Perhaps base classes that simply fetch the store from the owner would
>> be a good idea.
> Shall I open an Enhancement request?
>
>> I suppose it's also possible to use a store than can itself be
>> redirected to talk to different data sources.
> I already do something like that. My stores don't store the model
> values themselves, i.e. they don't store instance specific state. But
> they have some other data related that is common for certain groups of
> instances.
>
>>
>>
>> Eike Stepper wrote:
>>> Hi,
>>>
>>> Maybe I asked a similar question before but I couldn't find a thread
>>> anymore.
>>>
>>> EStoreEObjectImpl has got an eSetStore() method (even
>>> InternalEObject) which connects the instance to or disconnects it
>>> from an EStore.
>>> Unfortunately it is only usable *before* state has been set to the
>>> instance.
>>> After lists habe been created lazily it is not possible anymore to
>>> change the store because the it is stored in member fields of the
>>> lists.
>>> There is even not a setter to change the list store after
>>> construction ;-(
>>> With this implementation I'll have to iterate over the eSettings of
>>> the EStoreEObjectImpl and reflectively change the eStore field.
>>> Maybe I can overwrite createList() and createFeatureMap() to provide
>>> collections with a setter method that can be used after explicit
>>> downcasting.
>>>
>>> I'm not sure if at all there is a use case for different stores in
>>> EStoreEObjectImpl and its internal collections.
>>> It would at least be much nicer if abstract superclasses of these
>>> collections were provided that have an abstract eStore() method that
>>> I could implement to return the store of the owner.
>>>
>>> What do you think?
>>>
>>> Cheers
>>> /Eike
>>>
Re: Swapping EStores [message #411325 is a reply to message #411324] Mon, 23 July 2007 14:26 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5574
Registered: July 2009
Senior Member
Ed,

I entered this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487

Somehow I hit Enter before the summary was complete ;-(

It should be "Provide stateless EstoreEList and EStoreFeatureMap base classes"


Cheers
/Eike


Ed Merks schrieb:
> Eike,
>
> Yes, please open an enhancement request.
>
>
> Eike Stepper wrote:
>> Ed Merks schrieb:
>>> Eike,
>>>
>>> Perhaps base classes that simply fetch the store from the owner
>>> would be a good idea.
>> Shall I open an Enhancement request?
>>
>>> I suppose it's also possible to use a store than can itself be
>>> redirected to talk to different data sources.
>> I already do something like that. My stores don't store the model
>> values themselves, i.e. they don't store instance specific state. But
>> they have some other data related that is common for certain groups
>> of instances.
>>
>>>
>>>
>>> Eike Stepper wrote:
>>>> Hi,
>>>>
>>>> Maybe I asked a similar question before but I couldn't find a
>>>> thread anymore.
>>>>
>>>> EStoreEObjectImpl has got an eSetStore() method (even
>>>> InternalEObject) which connects the instance to or disconnects it
>>>> from an EStore.
>>>> Unfortunately it is only usable *before* state has been set to the
>>>> instance.
>>>> After lists habe been created lazily it is not possible anymore to
>>>> change the store because the it is stored in member fields of the
>>>> lists.
>>>> There is even not a setter to change the list store after
>>>> construction ;-(
>>>> With this implementation I'll have to iterate over the eSettings of
>>>> the EStoreEObjectImpl and reflectively change the eStore field.
>>>> Maybe I can overwrite createList() and createFeatureMap() to
>>>> provide collections with a setter method that can be used after
>>>> explicit downcasting.
>>>>
>>>> I'm not sure if at all there is a use case for different stores in
>>>> EStoreEObjectImpl and its internal collections.
>>>> It would at least be much nicer if abstract superclasses of these
>>>> collections were provided that have an abstract eStore() method
>>>> that I could implement to return the store of the owner.
>>>>
>>>> What do you think?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
Previous Topic:Serializing a dynamic model instance with xsi:schemaLocation
Next Topic:Setting EDefault to Inherited Constant Value
Goto Forum:
  


Current Time: Sun Nov 23 06:09:56 GMT 2014

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

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