Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Temporality][CDO] Delegating EStore
|
| Re: [Temporality][CDO] Delegating EStore [message #105076 is a reply to message #105014] |
Sun, 23 December 2007 10:06   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
jc schrieb:
> Hi,
>
> In my Temporality design I use a time aware EStore named TemporalEStoreImpl.
> Temporality needs to hook into EMF in this fashion because it gives full
> control over all data access and storing done to EMF objects.
>
> Eike, I know CDO also uses the EStore approach in its design.
>
> Maybe other projects also rely on a EStore hook to implement their feature.
> Are there any other features relying on an EStore hook?
>
Hard to say. I have the feeling that comparingly few questions with
respect to EStore have been asked on the EMF newsgroup over the last 5
years.
> Currently an EObject uses one EStore. Thus Temporality and CDO could not
> work together. In fact any feature that is based on an EStore hook cannot be
> used with another feature that relies on an EStore hook.
>
> I would like to propose is a mechanism for chaining EStore implementations
> so that an EObject could hold on to a chain of EStores. Please refer to this
> document for more details.
>
> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>
As I said in the other thread, I don't believe that it makes much sense
to connect an EObject to several stores at runtime. But it would be
great to free the developer from the burden of an exclusive decision at
generation time.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #105101 is a reply to message #105076] |
Sun, 23 December 2007 12:24 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eike,
As you say the use of EStore has not been widely explored. For example,
I've never used it personally to implement something. As with so much
of EMF, the support evolves based on actual needs in real applications.
So to be perfectly honest, I've never had a really good grasp of how or
when the store itself should be initialized; I can imagine having each
newly created object starting with a local/private store and eventually
when it's hooked up to a real context having that replaced by the "real"
store based on that context (at which point the cached local state could
be transferred over). The attached hook on a resource might be used for
such a purpose.
EStore is generally intended more as something of a
private/internal/implementation hook for the provider of the model
rather than something that clients of the API interact with directly.
Clients generally shouldn't know or care if a store is being used.
Eike Stepper wrote:
> jc schrieb:
>> Hi,
>>
>> In my Temporality design I use a time aware EStore named
>> TemporalEStoreImpl. Temporality needs to hook into EMF in this
>> fashion because it gives full control over all data access and
>> storing done to EMF objects.
>>
>> Eike, I know CDO also uses the EStore approach in its design.
>>
>> Maybe other projects also rely on a EStore hook to implement their
>> feature. Are there any other features relying on an EStore hook?
>>
> Hard to say. I have the feeling that comparingly few questions with
> respect to EStore have been asked on the EMF newsgroup over the last 5
> years.
>
>> Currently an EObject uses one EStore. Thus Temporality and CDO could
>> not work together. In fact any feature that is based on an EStore
>> hook cannot be used with another feature that relies on an EStore hook.
>>
>> I would like to propose is a mechanism for chaining EStore
>> implementations so that an EObject could hold on to a chain of
>> EStores. Please refer to this document for more details.
>>
>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>
> As I said in the other thread, I don't believe that it makes much
> sense to connect an EObject to several stores at runtime. But it would
> be great to free the developer from the burden of an exclusive
> decision at generation time.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #105276 is a reply to message #105101] |
Thu, 27 December 2007 11:05 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Ed Merks schrieb:
> Eike,
>
> As you say the use of EStore has not been widely explored. For
> example, I've never used it personally to implement something. As
> with so much of EMF, the support evolves based on actual needs in real
> applications. So to be perfectly honest, I've never had a really good
> grasp of how or when the store itself should be initialized; I can
> imagine having each newly created object starting with a local/private
> store and eventually when it's hooked up to a real context having that
> replaced by the "real" store based on that context (at which point the
> cached local state could be transferred over).
I'v added a CDOState to each object (and to each CDOResource), the two
main values being TRANSIENT and PERSISTENT. Objects are transient when
they are created and become persistent when they are attached to a
ResourceSet. The persistent state is a super state of CLEAN, DIRTY,
INVALID and CONFLICT. The states are managed by a central state machine
which in turn is triggered by events sent by a ResourceSet adapter
(add/remove Resources), by Resources (add/remove contents) and by the
store that is associated with the ResourceSet so that the objects can
delegate their access to.
I'm using the eSettings array of EStoreEObjectImpl to store the feature
values of objects when they are in transient state. When they leave this
state (to enter persistent state) I'm transferring the values into the
store. The store itself delegates value access to a data structure
(which I call Revision) per EObject. The store in this design has two
responsibilities: aquiring the appropriate Revision for an EObject
(thereby copying revisions into a transaction on write access) and
translating reference targets from EObject identity to internal IDs and
vice versa. This way the revisions are always unconnected and ready to
be transferred over a network or stored in a database.
> The attached hook on a resource might be used for such a purpose.
Using either the Resource or the ResourceSet seems to be a major
decision at the beginning of the design. I chose the ResourceSet to be
able to consistently support inter-resource cross references and because
I tend to see the Resources as persistent entities just like the objects
whereas the ResourceSet is really a pure transient entity that is used
on client-side to form a manageable view onto the persistent entities.
> EStore is generally intended more as something of a
> private/internal/implementation hook for the provider of the model
> rather than something that clients of the API interact with directly.
> Clients generally shouldn't know or care if a store is being used.
That's true, it's ideal for this purpose.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
>
> Eike Stepper wrote:
>> jc schrieb:
>>> Hi,
>>>
>>> In my Temporality design I use a time aware EStore named
>>> TemporalEStoreImpl. Temporality needs to hook into EMF in this
>>> fashion because it gives full control over all data access and
>>> storing done to EMF objects.
>>>
>>> Eike, I know CDO also uses the EStore approach in its design.
>>>
>>> Maybe other projects also rely on a EStore hook to implement their
>>> feature. Are there any other features relying on an EStore hook?
>>>
>> Hard to say. I have the feeling that comparingly few questions with
>> respect to EStore have been asked on the EMF newsgroup over the last
>> 5 years.
>>
>>> Currently an EObject uses one EStore. Thus Temporality and CDO could
>>> not work together. In fact any feature that is based on an EStore
>>> hook cannot be used with another feature that relies on an EStore hook.
>>>
>>> I would like to propose is a mechanism for chaining EStore
>>> implementations so that an EObject could hold on to a chain of
>>> EStores. Please refer to this document for more details.
>>>
>>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>>
>> As I said in the other thread, I don't believe that it makes much
>> sense to connect an EObject to several stores at runtime. But it
>> would be great to free the developer from the burden of an exclusive
>> decision at generation time.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #105351 is a reply to message #105276] |
Thu, 27 December 2007 13:13 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eike,
Thanks for the detailed explanation! I remember you talking about this
state machine thing with respect to CLEAN/DIRTY during the demo you gave
me. It's reassuring that the store works so well with this type of
approach! I guess that's why no one has come back and complained about
it. ;-)
Eike Stepper wrote:
> Ed Merks schrieb:
>> Eike,
>>
>> As you say the use of EStore has not been widely explored. For
>> example, I've never used it personally to implement something. As
>> with so much of EMF, the support evolves based on actual needs in
>> real applications. So to be perfectly honest, I've never had a
>> really good grasp of how or when the store itself should be
>> initialized; I can imagine having each newly created object starting
>> with a local/private store and eventually when it's hooked up to a
>> real context having that replaced by the "real" store based on that
>> context (at which point the cached local state could be transferred
>> over).
> I'v added a CDOState to each object (and to each CDOResource), the two
> main values being TRANSIENT and PERSISTENT. Objects are transient when
> they are created and become persistent when they are attached to a
> ResourceSet. The persistent state is a super state of CLEAN, DIRTY,
> INVALID and CONFLICT. The states are managed by a central state
> machine which in turn is triggered by events sent by a ResourceSet
> adapter (add/remove Resources), by Resources (add/remove contents) and
> by the store that is associated with the ResourceSet so that the
> objects can delegate their access to.
>
> I'm using the eSettings array of EStoreEObjectImpl to store the
> feature values of objects when they are in transient state. When they
> leave this state (to enter persistent state) I'm transferring the
> values into the store. The store itself delegates value access to a
> data structure (which I call Revision) per EObject. The store in this
> design has two responsibilities: aquiring the appropriate Revision for
> an EObject (thereby copying revisions into a transaction on write
> access) and translating reference targets from EObject identity to
> internal IDs and vice versa. This way the revisions are always
> unconnected and ready to be transferred over a network or stored in a
> database.
>
>> The attached hook on a resource might be used for such a purpose.
> Using either the Resource or the ResourceSet seems to be a major
> decision at the beginning of the design. I chose the ResourceSet to be
> able to consistently support inter-resource cross references and
> because I tend to see the Resources as persistent entities just like
> the objects whereas the ResourceSet is really a pure transient entity
> that is used on client-side to form a manageable view onto the
> persistent entities.
>
>> EStore is generally intended more as something of a
>> private/internal/implementation hook for the provider of the model
>> rather than something that clients of the API interact with
>> directly. Clients generally shouldn't know or care if a store is
>> being used.
> That's true, it's ideal for this purpose.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>>
>> Eike Stepper wrote:
>>> jc schrieb:
>>>> Hi,
>>>>
>>>> In my Temporality design I use a time aware EStore named
>>>> TemporalEStoreImpl. Temporality needs to hook into EMF in this
>>>> fashion because it gives full control over all data access and
>>>> storing done to EMF objects.
>>>>
>>>> Eike, I know CDO also uses the EStore approach in its design.
>>>>
>>>> Maybe other projects also rely on a EStore hook to implement their
>>>> feature. Are there any other features relying on an EStore hook?
>>>>
>>> Hard to say. I have the feeling that comparingly few questions with
>>> respect to EStore have been asked on the EMF newsgroup over the last
>>> 5 years.
>>>
>>>> Currently an EObject uses one EStore. Thus Temporality and CDO
>>>> could not work together. In fact any feature that is based on an
>>>> EStore hook cannot be used with another feature that relies on an
>>>> EStore hook.
>>>>
>>>> I would like to propose is a mechanism for chaining EStore
>>>> implementations so that an EObject could hold on to a chain of
>>>> EStores. Please refer to this document for more details.
>>>>
>>>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>>>
>>> As I said in the other thread, I don't believe that it makes much
>>> sense to connect an EObject to several stores at runtime. But it
>>> would be great to free the developer from the burden of an exclusive
>>> decision at generation time.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #612984 is a reply to message #105014] |
Sun, 23 December 2007 10:06 |
|
jc schrieb:
> Hi,
>
> In my Temporality design I use a time aware EStore named TemporalEStoreImpl.
> Temporality needs to hook into EMF in this fashion because it gives full
> control over all data access and storing done to EMF objects.
>
> Eike, I know CDO also uses the EStore approach in its design.
>
> Maybe other projects also rely on a EStore hook to implement their feature.
> Are there any other features relying on an EStore hook?
>
Hard to say. I have the feeling that comparingly few questions with
respect to EStore have been asked on the EMF newsgroup over the last 5
years.
> Currently an EObject uses one EStore. Thus Temporality and CDO could not
> work together. In fact any feature that is based on an EStore hook cannot be
> used with another feature that relies on an EStore hook.
>
> I would like to propose is a mechanism for chaining EStore implementations
> so that an EObject could hold on to a chain of EStores. Please refer to this
> document for more details.
>
> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>
As I said in the other thread, I don't believe that it makes much sense
to connect an EObject to several stores at runtime. But it would be
great to free the developer from the burden of an exclusive decision at
generation time.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #612988 is a reply to message #105076] |
Sun, 23 December 2007 12:24 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Eike,
As you say the use of EStore has not been widely explored. For example,
I've never used it personally to implement something. As with so much
of EMF, the support evolves based on actual needs in real applications.
So to be perfectly honest, I've never had a really good grasp of how or
when the store itself should be initialized; I can imagine having each
newly created object starting with a local/private store and eventually
when it's hooked up to a real context having that replaced by the "real"
store based on that context (at which point the cached local state could
be transferred over). The attached hook on a resource might be used for
such a purpose.
EStore is generally intended more as something of a
private/internal/implementation hook for the provider of the model
rather than something that clients of the API interact with directly.
Clients generally shouldn't know or care if a store is being used.
Eike Stepper wrote:
> jc schrieb:
>> Hi,
>>
>> In my Temporality design I use a time aware EStore named
>> TemporalEStoreImpl. Temporality needs to hook into EMF in this
>> fashion because it gives full control over all data access and
>> storing done to EMF objects.
>>
>> Eike, I know CDO also uses the EStore approach in its design.
>>
>> Maybe other projects also rely on a EStore hook to implement their
>> feature. Are there any other features relying on an EStore hook?
>>
> Hard to say. I have the feeling that comparingly few questions with
> respect to EStore have been asked on the EMF newsgroup over the last 5
> years.
>
>> Currently an EObject uses one EStore. Thus Temporality and CDO could
>> not work together. In fact any feature that is based on an EStore
>> hook cannot be used with another feature that relies on an EStore hook.
>>
>> I would like to propose is a mechanism for chaining EStore
>> implementations so that an EObject could hold on to a chain of
>> EStores. Please refer to this document for more details.
>>
>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>
> As I said in the other thread, I don't believe that it makes much
> sense to connect an EObject to several stores at runtime. But it would
> be great to free the developer from the burden of an exclusive
> decision at generation time.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #613012 is a reply to message #105101] |
Thu, 27 December 2007 11:05 |
|
Ed Merks schrieb:
> Eike,
>
> As you say the use of EStore has not been widely explored. For
> example, I've never used it personally to implement something. As
> with so much of EMF, the support evolves based on actual needs in real
> applications. So to be perfectly honest, I've never had a really good
> grasp of how or when the store itself should be initialized; I can
> imagine having each newly created object starting with a local/private
> store and eventually when it's hooked up to a real context having that
> replaced by the "real" store based on that context (at which point the
> cached local state could be transferred over).
I'v added a CDOState to each object (and to each CDOResource), the two
main values being TRANSIENT and PERSISTENT. Objects are transient when
they are created and become persistent when they are attached to a
ResourceSet. The persistent state is a super state of CLEAN, DIRTY,
INVALID and CONFLICT. The states are managed by a central state machine
which in turn is triggered by events sent by a ResourceSet adapter
(add/remove Resources), by Resources (add/remove contents) and by the
store that is associated with the ResourceSet so that the objects can
delegate their access to.
I'm using the eSettings array of EStoreEObjectImpl to store the feature
values of objects when they are in transient state. When they leave this
state (to enter persistent state) I'm transferring the values into the
store. The store itself delegates value access to a data structure
(which I call Revision) per EObject. The store in this design has two
responsibilities: aquiring the appropriate Revision for an EObject
(thereby copying revisions into a transaction on write access) and
translating reference targets from EObject identity to internal IDs and
vice versa. This way the revisions are always unconnected and ready to
be transferred over a network or stored in a database.
> The attached hook on a resource might be used for such a purpose.
Using either the Resource or the ResourceSet seems to be a major
decision at the beginning of the design. I chose the ResourceSet to be
able to consistently support inter-resource cross references and because
I tend to see the Resources as persistent entities just like the objects
whereas the ResourceSet is really a pure transient entity that is used
on client-side to form a manageable view onto the persistent entities.
> EStore is generally intended more as something of a
> private/internal/implementation hook for the provider of the model
> rather than something that clients of the API interact with directly.
> Clients generally shouldn't know or care if a store is being used.
That's true, it's ideal for this purpose.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
>
> Eike Stepper wrote:
>> jc schrieb:
>>> Hi,
>>>
>>> In my Temporality design I use a time aware EStore named
>>> TemporalEStoreImpl. Temporality needs to hook into EMF in this
>>> fashion because it gives full control over all data access and
>>> storing done to EMF objects.
>>>
>>> Eike, I know CDO also uses the EStore approach in its design.
>>>
>>> Maybe other projects also rely on a EStore hook to implement their
>>> feature. Are there any other features relying on an EStore hook?
>>>
>> Hard to say. I have the feeling that comparingly few questions with
>> respect to EStore have been asked on the EMF newsgroup over the last
>> 5 years.
>>
>>> Currently an EObject uses one EStore. Thus Temporality and CDO could
>>> not work together. In fact any feature that is based on an EStore
>>> hook cannot be used with another feature that relies on an EStore hook.
>>>
>>> I would like to propose is a mechanism for chaining EStore
>>> implementations so that an EObject could hold on to a chain of
>>> EStores. Please refer to this document for more details.
>>>
>>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>>
>> As I said in the other thread, I don't believe that it makes much
>> sense to connect an EObject to several stores at runtime. But it
>> would be great to free the developer from the burden of an exclusive
>> decision at generation time.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Temporality][CDO] Delegating EStore [message #613027 is a reply to message #105276] |
Thu, 27 December 2007 13:13 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Eike,
Thanks for the detailed explanation! I remember you talking about this
state machine thing with respect to CLEAN/DIRTY during the demo you gave
me. It's reassuring that the store works so well with this type of
approach! I guess that's why no one has come back and complained about
it. ;-)
Eike Stepper wrote:
> Ed Merks schrieb:
>> Eike,
>>
>> As you say the use of EStore has not been widely explored. For
>> example, I've never used it personally to implement something. As
>> with so much of EMF, the support evolves based on actual needs in
>> real applications. So to be perfectly honest, I've never had a
>> really good grasp of how or when the store itself should be
>> initialized; I can imagine having each newly created object starting
>> with a local/private store and eventually when it's hooked up to a
>> real context having that replaced by the "real" store based on that
>> context (at which point the cached local state could be transferred
>> over).
> I'v added a CDOState to each object (and to each CDOResource), the two
> main values being TRANSIENT and PERSISTENT. Objects are transient when
> they are created and become persistent when they are attached to a
> ResourceSet. The persistent state is a super state of CLEAN, DIRTY,
> INVALID and CONFLICT. The states are managed by a central state
> machine which in turn is triggered by events sent by a ResourceSet
> adapter (add/remove Resources), by Resources (add/remove contents) and
> by the store that is associated with the ResourceSet so that the
> objects can delegate their access to.
>
> I'm using the eSettings array of EStoreEObjectImpl to store the
> feature values of objects when they are in transient state. When they
> leave this state (to enter persistent state) I'm transferring the
> values into the store. The store itself delegates value access to a
> data structure (which I call Revision) per EObject. The store in this
> design has two responsibilities: aquiring the appropriate Revision for
> an EObject (thereby copying revisions into a transaction on write
> access) and translating reference targets from EObject identity to
> internal IDs and vice versa. This way the revisions are always
> unconnected and ready to be transferred over a network or stored in a
> database.
>
>> The attached hook on a resource might be used for such a purpose.
> Using either the Resource or the ResourceSet seems to be a major
> decision at the beginning of the design. I chose the ResourceSet to be
> able to consistently support inter-resource cross references and
> because I tend to see the Resources as persistent entities just like
> the objects whereas the ResourceSet is really a pure transient entity
> that is used on client-side to form a manageable view onto the
> persistent entities.
>
>> EStore is generally intended more as something of a
>> private/internal/implementation hook for the provider of the model
>> rather than something that clients of the API interact with
>> directly. Clients generally shouldn't know or care if a store is
>> being used.
> That's true, it's ideal for this purpose.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>>
>> Eike Stepper wrote:
>>> jc schrieb:
>>>> Hi,
>>>>
>>>> In my Temporality design I use a time aware EStore named
>>>> TemporalEStoreImpl. Temporality needs to hook into EMF in this
>>>> fashion because it gives full control over all data access and
>>>> storing done to EMF objects.
>>>>
>>>> Eike, I know CDO also uses the EStore approach in its design.
>>>>
>>>> Maybe other projects also rely on a EStore hook to implement their
>>>> feature. Are there any other features relying on an EStore hook?
>>>>
>>> Hard to say. I have the feeling that comparingly few questions with
>>> respect to EStore have been asked on the EMF newsgroup over the last
>>> 5 years.
>>>
>>>> Currently an EObject uses one EStore. Thus Temporality and CDO
>>>> could not work together. In fact any feature that is based on an
>>>> EStore hook cannot be used with another feature that relies on an
>>>> EStore hook.
>>>>
>>>> I would like to propose is a mechanism for chaining EStore
>>>> implementations so that an EObject could hold on to a chain of
>>>> EStores. Please refer to this document for more details.
>>>>
>>>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>>>
>>> As I said in the other thread, I don't believe that it makes much
>>> sense to connect an EObject to several stores at runtime. But it
>>> would be great to free the developer from the burden of an exclusive
>>> decision at generation time.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 10:20:23 GMT 2024
Powered by FUDForum. Page generated in 0.02116 seconds |
] 
Search
Help
Register
Login
Home
