Home » Modeling » EMF » Questions about Feature Delegation
|
| Re: Questions about Feature Delegation [message #425467 is a reply to message #425460] |
Wed, 26 November 2008 21:03   |
 Ed Merks
Messages: 33137
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Questions about Feature Delegation [message #425469 is a reply to message #425467] |
Wed, 26 November 2008 21:27 |
Simon Mc Duff
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 #425693 is a reply to message #425469] |
Fri, 05 December 2008 08:02 |
Anders Forsell
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 |
|
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
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Questions about Feature Delegation [message #425707 is a reply to message #425702] |
Fri, 05 December 2008 11:23 |
Ed Merks
Messages: 33137
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
>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:03:23 GMT 2024
Powered by FUDForum. Page generated in 0.03012 seconds |
] 
Search
Help
Register
Login
Home
