Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Questions about Feature Delegation
Questions about Feature Delegation [message #425460] Wed, 26 November 2008 17:42 Go to next message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 480
Registered: July 2009
Senior Member
I'm using the Reflective Feature Delegation option and setting my root
extends impl to EStoreEObjectImpl. I have a few questions:

1) I notice (based on the NPE that occurs otherwise) that I must set
eStore before using my generated objects. Has there been (or is there an
option) to generate the factory to do this automatically to some specified
default (my thought would be to set a default that makes the object behave
like "regular", non-delegated EObject)?

2) Using the Eclipse Java hierarchy, there appears to be only one concrete
impl of EStore called EStoreImpl. This impl is marked as being
"temporary" and subject to removal. It would be nice to have a default
implementation like this for the use case where you want to construct an
instance locally, initialize it in memory and then submit it to whatever
management entity before it is rebound to a different storage mechanism.

3) I notice that in EStoreEObjectImpl the method eIsCaching, which
controls whether or not delegated values are cached locally, is hard-coded
to true. Is there a way to generate an override to false or is it
generally expected that such customizations would be made by sub-classing
EStoreEObjectImpl and then using that as the root extends impl?


Thanks,

Cameron
Re: Questions about Feature Delegation [message #425467 is a reply to message #425460] Wed, 26 November 2008 21:03 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30911
Registered: July 2009
Senior Member
Cameron,

Comments below.

Cameron Bateman wrote:
> I'm using the Reflective Feature Delegation option and setting my root
> extends impl to EStoreEObjectImpl. I have a few questions:
>
> 1) I notice (based on the NPE that occurs otherwise) that I must set
> eStore before using my generated objects.
Yes.
> Has there been (or is there an option) to generate the factory to do
> this automatically to some specified default (my thought would be to
> set a default that makes the object behave like "regular",
> non-delegated EObject)?
No, because a factory is a global singleton and it really doesn't make
sense for there to be a global singleton store.

What Eike does with CDO is make an object without a store behave just
like a DynamicEObjectImpl so it keeps the data in the settings array.
Only once the object is added to a store-based resource (e.g,
CDOResourceImpl) is a store associated and at that point, the
"transient" state of the object is transfered to the store. It's a
really nice design.
>
> 2) Using the Eclipse Java hierarchy, there appears to be only one
> concrete impl of EStore called EStoreImpl.
Yes.
> This impl is marked as being "temporary" and subject to removal.
It's just a sample.
> It would be nice to have a default implementation like this for the
> use case where you want to construct an instance locally, initialize
> it in memory and then submit it to whatever management entity before
> it is rebound to a different storage mechanism.
I think Eike's design is nicer because it's very space efficient. At
ESE I talked to some folks about having in the core runtime a
store-based implementation that works effectively like a
DynamicEobjectImpl until a store is associated so that folks can
generate models that work without CDO but also can take advantage of all
of CDO's facilities when used in that context. I haven't had a chance
to chat with Eike about that given that I've been in France all week.
Perhaps you should open a bugzilla feature request to track this idea...
>
> 3) I notice that in EStoreEObjectImpl the method eIsCaching, which
> controls whether or not delegated values are cached locally, is
> hard-coded to true.
We do this type of thing quite often because a good JIT implementation
can treat this as a compile time constant to effectively prune the code
path such that no actual function call occurs at runtime.
> Is there a way to generate an override to false or is it generally
> expected that such customizations would be made by sub-classing
> EStoreEObjectImpl and then using that as the root extends impl?
No, but it's very easy to provide your own base class and use that
instead. Much like SDO provides EDataObjectImpl as the root extends
class...

If we can come up with a good base class that CDO can exploit but
doesn't have CDO dependencies, that would be a good thing. I'll need to
talk to Eike about that though...
>
>
> Thanks,
>
> Cameron
>
Re: Questions about Feature Delegation [message #425469 is a reply to message #425467] Wed, 26 November 2008 21:27 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I would like to add a small comments about the approach that CDO took.

At the beginning we stored all the transient data in
EStoreEObjectImpl.eSettings.
The problem we had was even if eIsCache == false, the wrapper list are
stored there. Since the wrapper doesn't contains the data... we needed a
place to store the list where the data would actually be stored (not
only the wrapper).

Since
251544: Instance of list are not the same for the following transition
transient/new persisted/transient resulting strange behavior (NPE)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251544

wrapper list are kept in EStoreEObjectImpl.eSettings (Transient and
Persistent - standard way). We've created CDOObjectImpl.cdoSettings to
store the data in a transient mode. It is working with the following
singleton CDOStoreSettingsImpl. (implements InternalEObject.EStore)

If people are interesting in Ed idea's... to push these concept to a
base class...I think many people could benefit from it... (us the first one)

Simon


Ed Merks wrote:
> Cameron,
>
> Comments below.
>
> Cameron Bateman wrote:
>> I'm using the Reflective Feature Delegation option and setting my root
>> extends impl to EStoreEObjectImpl. I have a few questions:
>>
>> 1) I notice (based on the NPE that occurs otherwise) that I must set
>> eStore before using my generated objects.
> Yes.
>> Has there been (or is there an option) to generate the factory to do
>> this automatically to some specified default (my thought would be to
>> set a default that makes the object behave like "regular",
>> non-delegated EObject)?
> No, because a factory is a global singleton and it really doesn't make
> sense for there to be a global singleton store.
>
> What Eike does with CDO is make an object without a store behave just
> like a DynamicEObjectImpl so it keeps the data in the settings array.
> Only once the object is added to a store-based resource (e.g,
> CDOResourceImpl) is a store associated and at that point, the
> "transient" state of the object is transfered to the store. It's a
> really nice design.


>>
>> 2) Using the Eclipse Java hierarchy, there appears to be only one
>> concrete impl of EStore called EStoreImpl.
> Yes.
>> This impl is marked as being "temporary" and subject to removal.
> It's just a sample.
>> It would be nice to have a default implementation like this for the
>> use case where you want to construct an instance locally, initialize
>> it in memory and then submit it to whatever management entity before
>> it is rebound to a different storage mechanism.
> I think Eike's design is nicer because it's very space efficient. At
> ESE I talked to some folks about having in the core runtime a
> store-based implementation that works effectively like a
> DynamicEobjectImpl until a store is associated so that folks can
> generate models that work without CDO but also can take advantage of all
> of CDO's facilities when used in that context. I haven't had a chance
> to chat with Eike about that given that I've been in France all week.
> Perhaps you should open a bugzilla feature request to track this idea...
>>
>> 3) I notice that in EStoreEObjectImpl the method eIsCaching, which
>> controls whether or not delegated values are cached locally, is
>> hard-coded to true.
> We do this type of thing quite often because a good JIT implementation
> can treat this as a compile time constant to effectively prune the code
> path such that no actual function call occurs at runtime.
>> Is there a way to generate an override to false or is it generally
>> expected that such customizations would be made by sub-classing
>> EStoreEObjectImpl and then using that as the root extends impl?
> No, but it's very easy to provide your own base class and use that
> instead. Much like SDO provides EDataObjectImpl as the root extends
> class...
>
> If we can come up with a good base class that CDO can exploit but
> doesn't have CDO dependencies, that would be a good thing. I'll need to
> talk to Eike about that though...
>>
>>
>> Thanks,
>>
>> Cameron
>>
Re: Questions about Feature Delegation [message #425470 is a reply to message #425469] Wed, 26 November 2008 21:40 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 480
Registered: July 2009
Senior Member
> If people are interesting in Ed idea's... to push these concept to a
> base class...I think many people could benefit from it... (us the first one)

I am certainly interest in this line as well. I will open an enhancement
request and also start looking more at the CDO code.
Re: Questions about Feature Delegation [message #425471 is a reply to message #425470] Wed, 26 November 2008 21:46 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 480
Registered: July 2009
Senior Member
> I will open an enhancement request...

https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706
Re: Questions about Feature Delegation [message #425693 is a reply to message #425469] Fri, 05 December 2008 08:02 Go to previous messageGo to next message
Anders Forsell is currently offline Anders ForsellFriend
Messages: 127
Registered: July 2009
Senior Member
If I understand this correctly I believe Ed's idea would be great since
an application typically needs to work in-memory and with XMI
persistence with smaller models and, without regeneration of the model,
should work with larger models and distribution using CDO's model
repository.
I don't like the idea of having to generate two different models for
these two use-cases.

---
Anders

Simon McDuff wrote:
> I would like to add a small comments about the approach that CDO took.
>
> At the beginning we stored all the transient data in
> EStoreEObjectImpl.eSettings.
> The problem we had was even if eIsCache == false, the wrapper list are
> stored there. Since the wrapper doesn't contains the data... we needed a
> place to store the list where the data would actually be stored (not
> only the wrapper).
>
> Since
> 251544: Instance of list are not the same for the following transition
> transient/new persisted/transient resulting strange behavior (NPE)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251544
>
> wrapper list are kept in EStoreEObjectImpl.eSettings (Transient and
> Persistent - standard way). We've created CDOObjectImpl.cdoSettings to
> store the data in a transient mode. It is working with the following
> singleton CDOStoreSettingsImpl. (implements InternalEObject.EStore)
>
> If people are interesting in Ed idea's... to push these concept to a
> base class...I think many people could benefit from it... (us the first
> one)
>
> Simon
>
>
> Ed Merks wrote:
>> Cameron,
>>
>> Comments below.
>>
>> Cameron Bateman wrote:
>>> I'm using the Reflective Feature Delegation option and setting my
>>> root extends impl to EStoreEObjectImpl. I have a few questions:
>>>
>>> 1) I notice (based on the NPE that occurs otherwise) that I must set
>>> eStore before using my generated objects.
>> Yes.
>>> Has there been (or is there an option) to generate the factory to
>>> do this automatically to some specified default (my thought would be
>>> to set a default that makes the object behave like "regular",
>>> non-delegated EObject)?
>> No, because a factory is a global singleton and it really doesn't make
>> sense for there to be a global singleton store.
>>
>> What Eike does with CDO is make an object without a store behave just
>> like a DynamicEObjectImpl so it keeps the data in the settings array.
>> Only once the object is added to a store-based resource (e.g,
>> CDOResourceImpl) is a store associated and at that point, the
>> "transient" state of the object is transfered to the store. It's a
>> really nice design.
>
>
>>>
>>> 2) Using the Eclipse Java hierarchy, there appears to be only one
>>> concrete impl of EStore called EStoreImpl.
>> Yes.
>>> This impl is marked as being "temporary" and subject to removal.
>> It's just a sample.
>>> It would be nice to have a default implementation like this for the
>>> use case where you want to construct an instance locally, initialize
>>> it in memory and then submit it to whatever management entity before
>>> it is rebound to a different storage mechanism.
>> I think Eike's design is nicer because it's very space efficient. At
>> ESE I talked to some folks about having in the core runtime a
>> store-based implementation that works effectively like a
>> DynamicEobjectImpl until a store is associated so that folks can
>> generate models that work without CDO but also can take advantage of
>> all of CDO's facilities when used in that context. I haven't had a
>> chance to chat with Eike about that given that I've been in France all
>> week. Perhaps you should open a bugzilla feature request to track
>> this idea...
>>>
>>> 3) I notice that in EStoreEObjectImpl the method eIsCaching, which
>>> controls whether or not delegated values are cached locally, is
>>> hard-coded to true.
>> We do this type of thing quite often because a good JIT implementation
>> can treat this as a compile time constant to effectively prune the
>> code path such that no actual function call occurs at runtime.
>>> Is there a way to generate an override to false or is it generally
>>> expected that such customizations would be made by sub-classing
>>> EStoreEObjectImpl and then using that as the root extends impl?
>> No, but it's very easy to provide your own base class and use that
>> instead. Much like SDO provides EDataObjectImpl as the root extends
>> class...
>>
>> If we can come up with a good base class that CDO can exploit but
>> doesn't have CDO dependencies, that would be a good thing. I'll need
>> to talk to Eike about that though...
>>>
>>>
>>> Thanks,
>>>
>>> Cameron
>>>
Re: Questions about Feature Delegation [message #425702 is a reply to message #425693] Fri, 05 December 2008 11:01 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6483
Registered: July 2009
Senior Member
Anders,

I agree with you that it would be great if arbitrary models could be
used with CDO without the necessity of regeneration, but I'm biased. I
fear that there are people out there who are concerned about performance
penalty for the simpler cases. As far as I understood Ed this issue is
not about forcing all models into reflective/dynamic delegation by
default. Rather it is about providing a usable default implementation
that can be used with reflective delegation without requiring CDO
dependencies. Ed?

Cheers
/Eike

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




Anders Forsell schrieb:
> If I understand this correctly I believe Ed's idea would be great
> since an application typically needs to work in-memory and with XMI
> persistence with smaller models and, without regeneration of the
> model, should work with larger models and distribution using CDO's
> model repository.
> I don't like the idea of having to generate two different models for
> these two use-cases.
>
> ---
> Anders
>
> Simon McDuff wrote:
>> I would like to add a small comments about the approach that CDO took.
>>
>> At the beginning we stored all the transient data in
>> EStoreEObjectImpl.eSettings.
>> The problem we had was even if eIsCache == false, the wrapper list
>> are stored there. Since the wrapper doesn't contains the data... we
>> needed a place to store the list where the data would actually be
>> stored (not only the wrapper).
>>
>> Since
>> 251544: Instance of list are not the same for the following
>> transition transient/new persisted/transient resulting strange
>> behavior (NPE)
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251544
>>
>> wrapper list are kept in EStoreEObjectImpl.eSettings (Transient and
>> Persistent - standard way). We've created CDOObjectImpl.cdoSettings
>> to store the data in a transient mode. It is working with the
>> following singleton CDOStoreSettingsImpl. (implements
>> InternalEObject.EStore)
>>
>> If people are interesting in Ed idea's... to push these concept to a
>> base class...I think many people could benefit from it... (us the
>> first one)
>>
>> Simon
>>
>>
>> Ed Merks wrote:
>>> Cameron,
>>>
>>> Comments below.
>>>
>>> Cameron Bateman wrote:
>>>> I'm using the Reflective Feature Delegation option and setting my
>>>> root extends impl to EStoreEObjectImpl. I have a few questions:
>>>>
>>>> 1) I notice (based on the NPE that occurs otherwise) that I must
>>>> set eStore before using my generated objects.
>>> Yes.
>>>> Has there been (or is there an option) to generate the factory to
>>>> do this automatically to some specified default (my thought would
>>>> be to set a default that makes the object behave like "regular",
>>>> non-delegated EObject)?
>>> No, because a factory is a global singleton and it really doesn't
>>> make sense for there to be a global singleton store.
>>>
>>> What Eike does with CDO is make an object without a store behave
>>> just like a DynamicEObjectImpl so it keeps the data in the settings
>>> array. Only once the object is added to a store-based resource
>>> (e.g, CDOResourceImpl) is a store associated and at that point, the
>>> "transient" state of the object is transfered to the store. It's a
>>> really nice design.
>>
>>
>>>>
>>>> 2) Using the Eclipse Java hierarchy, there appears to be only one
>>>> concrete impl of EStore called EStoreImpl.
>>> Yes.
>>>> This impl is marked as being "temporary" and subject to removal.
>>> It's just a sample.
>>>> It would be nice to have a default implementation like this for
>>>> the use case where you want to construct an instance locally,
>>>> initialize it in memory and then submit it to whatever management
>>>> entity before it is rebound to a different storage mechanism.
>>> I think Eike's design is nicer because it's very space efficient.
>>> At ESE I talked to some folks about having in the core runtime a
>>> store-based implementation that works effectively like a
>>> DynamicEobjectImpl until a store is associated so that folks can
>>> generate models that work without CDO but also can take advantage of
>>> all of CDO's facilities when used in that context. I haven't had a
>>> chance to chat with Eike about that given that I've been in France
>>> all week. Perhaps you should open a bugzilla feature request to
>>> track this idea...
>>>>
>>>> 3) I notice that in EStoreEObjectImpl the method eIsCaching, which
>>>> controls whether or not delegated values are cached locally, is
>>>> hard-coded to true.
>>> We do this type of thing quite often because a good JIT
>>> implementation can treat this as a compile time constant to
>>> effectively prune the code path such that no actual function call
>>> occurs at runtime.
>>>> Is there a way to generate an override to false or is it
>>>> generally expected that such customizations would be made by
>>>> sub-classing EStoreEObjectImpl and then using that as the root
>>>> extends impl?
>>> No, but it's very easy to provide your own base class and use that
>>> instead. Much like SDO provides EDataObjectImpl as the root extends
>>> class...
>>>
>>> If we can come up with a good base class that CDO can exploit but
>>> doesn't have CDO dependencies, that would be a good thing. I'll
>>> need to talk to Eike about that though...
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Cameron
>>>>


Re: Questions about Feature Delegation [message #425707 is a reply to message #425702] Fri, 05 December 2008 11:23 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30911
Registered: July 2009
Senior Member
Guys,

I think both your comments are true. Certainly we're not likely to
change defaults to use something other than the simple default
generation pattern we've been using, but the idea is definitely to
provide, in the core runtime, an implementation that can be used without
CDO, and in that case behaves much like DynamicEObjectImpl does, i.e.,
use an array of slots to store the values, and then also, when a store
is present, delegates all access to the store. So definitely the goal
is that the one implementation of the model classes can serve both
purposes well.


Eike Stepper wrote:
> Anders,
>
> I agree with you that it would be great if arbitrary models could be
> used with CDO without the necessity of regeneration, but I'm biased. I
> fear that there are people out there who are concerned about
> performance penalty for the simpler cases. As far as I understood Ed
> this issue is not about forcing all models into reflective/dynamic
> delegation by default. Rather it is about providing a usable default
> implementation that can be used with reflective delegation without
> requiring CDO dependencies. Ed?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
>
> Anders Forsell schrieb:
>> If I understand this correctly I believe Ed's idea would be great
>> since an application typically needs to work in-memory and with XMI
>> persistence with smaller models and, without regeneration of the
>> model, should work with larger models and distribution using CDO's
>> model repository.
>> I don't like the idea of having to generate two different models for
>> these two use-cases.
>>
>> ---
>> Anders
>>
>> Simon McDuff wrote:
>>> I would like to add a small comments about the approach that CDO took.
>>>
>>> At the beginning we stored all the transient data in
>>> EStoreEObjectImpl.eSettings.
>>> The problem we had was even if eIsCache == false, the wrapper list
>>> are stored there. Since the wrapper doesn't contains the data... we
>>> needed a place to store the list where the data would actually be
>>> stored (not only the wrapper).
>>>
>>> Since
>>> 251544: Instance of list are not the same for the following
>>> transition transient/new persisted/transient resulting strange
>>> behavior (NPE)
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251544
>>>
>>> wrapper list are kept in EStoreEObjectImpl.eSettings (Transient and
>>> Persistent - standard way). We've created CDOObjectImpl.cdoSettings
>>> to store the data in a transient mode. It is working with the
>>> following singleton CDOStoreSettingsImpl. (implements
>>> InternalEObject.EStore)
>>>
>>> If people are interesting in Ed idea's... to push these concept to a
>>> base class...I think many people could benefit from it... (us the
>>> first one)
>>>
>>> Simon
>>>
>>>
>>> Ed Merks wrote:
>>>> Cameron,
>>>>
>>>> Comments below.
>>>>
>>>> Cameron Bateman wrote:
>>>>> I'm using the Reflective Feature Delegation option and setting my
>>>>> root extends impl to EStoreEObjectImpl. I have a few questions:
>>>>>
>>>>> 1) I notice (based on the NPE that occurs otherwise) that I must
>>>>> set eStore before using my generated objects.
>>>> Yes.
>>>>> Has there been (or is there an option) to generate the factory
>>>>> to do this automatically to some specified default (my thought
>>>>> would be to set a default that makes the object behave like
>>>>> "regular", non-delegated EObject)?
>>>> No, because a factory is a global singleton and it really doesn't
>>>> make sense for there to be a global singleton store.
>>>>
>>>> What Eike does with CDO is make an object without a store behave
>>>> just like a DynamicEObjectImpl so it keeps the data in the settings
>>>> array. Only once the object is added to a store-based resource
>>>> (e.g, CDOResourceImpl) is a store associated and at that point, the
>>>> "transient" state of the object is transfered to the store. It's a
>>>> really nice design.
>>>
>>>
>>>>>
>>>>> 2) Using the Eclipse Java hierarchy, there appears to be only one
>>>>> concrete impl of EStore called EStoreImpl.
>>>> Yes.
>>>>> This impl is marked as being "temporary" and subject to removal.
>>>> It's just a sample.
>>>>> It would be nice to have a default implementation like this for
>>>>> the use case where you want to construct an instance locally,
>>>>> initialize it in memory and then submit it to whatever management
>>>>> entity before it is rebound to a different storage mechanism.
>>>> I think Eike's design is nicer because it's very space efficient.
>>>> At ESE I talked to some folks about having in the core runtime a
>>>> store-based implementation that works effectively like a
>>>> DynamicEobjectImpl until a store is associated so that folks can
>>>> generate models that work without CDO but also can take advantage
>>>> of all of CDO's facilities when used in that context. I haven't
>>>> had a chance to chat with Eike about that given that I've been in
>>>> France all week. Perhaps you should open a bugzilla feature
>>>> request to track this idea...
>>>>>
>>>>> 3) I notice that in EStoreEObjectImpl the method eIsCaching, which
>>>>> controls whether or not delegated values are cached locally, is
>>>>> hard-coded to true.
>>>> We do this type of thing quite often because a good JIT
>>>> implementation can treat this as a compile time constant to
>>>> effectively prune the code path such that no actual function call
>>>> occurs at runtime.
>>>>> Is there a way to generate an override to false or is it
>>>>> generally expected that such customizations would be made by
>>>>> sub-classing EStoreEObjectImpl and then using that as the root
>>>>> extends impl?
>>>> No, but it's very easy to provide your own base class and use that
>>>> instead. Much like SDO provides EDataObjectImpl as the root
>>>> extends class...
>>>>
>>>> If we can come up with a good base class that CDO can exploit but
>>>> doesn't have CDO dependencies, that would be a good thing. I'll
>>>> need to talk to Eike about that though...
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Cameron
>>>>>
Previous Topic:Problem with URIs in XMIResource
Next Topic:How to cross reference between models.
Goto Forum:
  


Current Time: Wed Feb 26 17:01:17 GMT 2020

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

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

Back to the top