Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Temporality][CDO][Teneo]Delegating EStore and Root extends class
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #108326 is a reply to message #108304] |
Sat, 26 January 2008 09:33   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------050303060002020302090607
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Jean-Claude,
Comments below...
jc schrieb:
> Hi,
>
> I would like to open a discussion on the topic of sharing hook points into
> the EStore and the Root extends class.
>
> As you may already know if two features say CDO and Temporality are to be
> used simultaneously we need to agree on a way to chain EStores.
>
> Also we need figure out what to do about the Root extends class.
>
> I believe Temporality could be all implemented from an EStore as long as the
> following events are added to the EStore interface.
> - creation event (the EObject is being instantiated.)
>
The EStore interface has a
| *public *EObject create(EClass eClass);|
But I could never figure out who/what/when is expected to call it. My
store implementation just throws an UOE. If an EStore represents some
sort of persistence container that is associated with a set of
*persistent* objects (i.e. a Resource or a ResourceSet) then I believe
that object creation always occurs outside of this container in a first
stage, i.e. object creation is always a *transient* operation. These
transient objects can only become persistent when they are added to
containment references of objects that are already persistent. With CDO
the persistent root objects are the Resources themselves (which really
implement EObject!).
So I even don't have an idea what the semantics of EStore.create(EClass)
should be.
> - get/set containment
>
It is possible to derive these events from other events
(set/unset/add/remove) in combination with knowledge about the
underlying model (containment references). This is also the way CDO
implements EStore.
> Here's a document sketching out a possible solution for delegating EStores:
> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>
> Here's a description of the Temporality project:
> http://www.eclipse.org/modeling/emft/?project=temporality
>
> Eike already opened a bug regarding the issue of delegating EStores:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>
> I will have a look at the CDO implementation to get a better understanding
> of how it hooks itself in EMF.
>
You should start with the classes CDOObjectImpl, CDOStore and
CDOStateMachine.
Please ask me if you need assistance ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
--------------050303060002020302090607
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">
Hi Jean-Claude,<br>
<br>
Comments below...<br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fndkc0$rfp$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
I would like to open a discussion on the topic of sharing hook points into
the EStore and the Root extends class.
As you may already know if two features say CDO and Temporality are to be
used simultaneously we need to agree on a way to chain EStores.
Also we need figure out what to do about the Root extends class.
I believe Temporality could be all implemented from an EStore as long as the
following events are added to the EStore interface.
- creation event (the EObject is being instantiated.)
</pre>
</blockquote>
The EStore interface has a <br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #108388 is a reply to message #108326] |
Sat, 26 January 2008 13:48 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------090402000707010705080207
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Comments below.
Eike Stepper wrote:
> Hi Jean-Claude,
>
> Comments below...
>
>
> jc schrieb:
>> Hi,
>>
>> I would like to open a discussion on the topic of sharing hook points into
>> the EStore and the Root extends class.
>>
>> As you may already know if two features say CDO and Temporality are to be
>> used simultaneously we need to agree on a way to chain EStores.
>>
>> Also we need figure out what to do about the Root extends class.
>>
>> I believe Temporality could be all implemented from an EStore as long as the
>> following events are added to the EStore interface.
>> - creation event (the EObject is being instantiated.)
>>
> The EStore interface has a
> | *public *EObject create(EClass eClass);|
>
>
> But I could never figure out who/what/when is expected to call it. My
> store implementation just throws an UOE. If an EStore represents some
> sort of persistence container that is associated with a set of
> *persistent* objects (i.e. a Resource or a ResourceSet) then I believe
> that object creation always occurs outside of this container in a
> first stage, i.e. object creation is always a *transient* operation.
> These transient objects can only become persistent when they are added
> to containment references of objects that are already persistent. With
> CDO the persistent root objects are the Resources themselves (which
> really implement EObject!).
>
> So I even don't have an idea what the semantics of
> EStore.create(EClass) should be.
This is one of the problems of defining an API without the direct
interaction with the associated users of the API. Given that a factory
typically creates things, it wasn't entirely obvious to me how this
ought to be used and given that it doesn't make so much sense for the
shared factory to be associated with only one store, it doesn't seem
terribly useful. Note that data graphs and data objects have create
methods and that the APIs were designed to support folks who were
implementing some lazy SDO stuff, so likely they hooked the data graph
to a store could funnel all creation to that store.
>
>> - get/set containment
>>
> It is possible to derive these events from other events
> (set/unset/add/remove) in combination with knowledge about the
> underlying model (containment references). This is also the way CDO
> implements EStore.
Yes, change in containers is implicit in changes to containment references.
>
>> Here's a document sketching out a possible solution for delegating EStores:
>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>
>> Here's a description of the Temporality project:
>> http://www.eclipse.org/modeling/emft/?project=temporality
>>
>> Eike already opened a bug regarding the issue of delegating EStores:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>>
>> I will have a look at the CDO implementation to get a better understanding
>> of how it hooks itself in EMF.
>>
> You should start with the classes CDOObjectImpl, CDOStore and
> CDOStateMachine.
> Please ask me if you need assistance ;-)
I think Eike's done a great job building a meaningful implementation
around these APIs. It's interesting how he's got it set up to use a
dynamic type of implementation to back the data until the object becomes
associated with a store and at that point the data is transferred over.
Very innovative...
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
--------------090402000707010705080207
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">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fneupe$5ft$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
Hi Jean-Claude,<br>
<br>
Comments below...<br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fndkc0$rfp$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
I would like to open a discussion on the topic of sharing hook points into
the EStore and the Root extends class.
As you may already know if two features say CDO and Temporality are to be
used simultaneously we need to agree on a way to chain EStores.
Also we need figure out what to do about the Root extends class.
I believe Temporality could be all implemented from an EStore as long as the
following events are added to the EStore interface.
- creation event (the EObject is being instantiated.)
</pre>
</blockquote>
The EStore interface has a <br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; ">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = --><!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">
|
|
| |
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #110500 is a reply to message #108388] |
Wed, 30 January 2008 15:05 |
 Jean-Claude Cote
Messages: 56
Registered: July 2009 |
Member |
|
|
Hi Eike,
As I suspected you have the same hooks in your CDOObjectImpl base class
(Root Implements Class) as I do in my base class TemporalBaseEObjectImpl.
That is you trap getting/setting the container and creation.
creation
========
private static final ContextTracer TRACER = new
ContextTracer(OM.DEBUG_OBJECT, CDOObjectImpl.class);
public CDOObjectImpl()
{
state = CDOState.TRANSIENT;
eContainer = null;
}
no caching
==========
/**
* Don't cache non-transient features in this CDOObject's {@link
#eSettings()}.
*/
@Override
protected boolean eIsCaching()
{
return false;
}
getting/setting container
=========================
public InternalEObject eInternalContainer()
{ ...
// Delegate to CDOStore
container = getStore().getContainer(this);
protected void eBasicSetContainer(InternalEObject newContainer, int
newContainerFeatureID)
{ ...
// Delegate to CDOStore
getStore().setContainer(this, newContainer, newContainerFeatureID);
In CDOStore you added a setContainer method, in here you pass the request to
the correct version:
public void setContainer(InternalEObject eObject, InternalEObject
newContainer, int newContainerFeatureID)
{
InternalCDOObject cdoObject = getCDOObject(eObject);
if (TRACER.isEnabled())
{
TRACER.format("setContainer({0}, {1}, {2})", cdoObject, newContainer,
newContainerFeatureID);
}
CDOID containerID =
(CDOID)((CDOViewImpl)cdoObject.cdoView()).convertObjectToID( newContainer);
CDOFeatureDelta delta = new CDOContainerFeatureDeltaImpl(containerID,
newContainerFeatureID);
InternalCDORevision revision = getRevisionForWriting(cdoObject, delta);
revision.setContainerID(containerID);
revision.setContainingFeatureID(newContainerFeatureID);
}
public InternalEObject getContainer(InternalEObject eObject)
{
InternalCDOObject cdoObject = getCDOObject(eObject);
if (TRACER.isEnabled())
{
TRACER.format("getContainer({0})", cdoObject);
}
InternalCDORevision revision = getRevisionForReading(cdoObject);
CDOID id = revision.getContainerID();
return
(InternalEObject)((CDOViewImpl)cdoObject.cdoView()).convertI DToObject(id);
}
I did the same thing in TemporalBaseEObjectImpl, except that I'm not passing
it to my EStore however I could have. But the idea is the same. I trap
containment getting and setting and handle them.
creation
========
public TemporalBaseEObjectImpl(EClass eClass) {
super(eClass, new TemporalEStoreImpl(new EStoreEObjectImpl.EStoreImpl()));
TemporalUtil.initTemporal(this);
}
no caching
==========
/**
* Overriden to prevent base class from caching the values returned from
the EStore.
* We want to be able to control the retrieval of data through the getters.
*/
protected boolean eIsCaching(){
return false;
}
getting/setting container
=========================
/**
* JCC: added this to support versioning of containment features.
* To version the containment reference we need to hook into the setter for
it.
* This method is overriden to give us access to the setting of the
containment reference.
* What this method does is try to find a version to delegate this setter
to. If a version
* is found it delegates the setter to it. If this is the version on which
it should be
* performed it does not delegate (it passes the request to its base class).
*/
public NotificationChain eBasicSetContainer(InternalEObject newContainer,
int newContainerFeatureID,
NotificationChain msgs) {
if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
InternalEObject version =
TemporalEStoreHandler.findVersionToDelegateMutatorTo(this, null);
if (version != null) {
return version.eBasicSetContainer(newContainer, newContainerFeatureID,
msgs);
}
}
return super.eBasicSetContainer(newContainer, newContainerFeatureID, msgs);
}
/**
* JCC: added this to support versioning of containment features.
* To version the containment reference we need to hook into the getter for
it.
* This method is overriden to give us access to the getter of the
containment reference.
* What this method does is try to find a version to delegate this getter
to. If a version
* is found it delegates the getter to it. If this is the version on which
it should be
* performed it does not delegate (it passes the request to its base class).
*/
public InternalEObject eInternalContainer() {
if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
InternalEObject version =
TemporalEStoreHandler.findVersionToDelegateAccessorTo(this, null);
if (version != null) {
return version.eInternalContainer();
}
}
return super.eInternalContainer();
}
Since we have the same requirements we should try to come up with a new
EStore interface with the added setContainer and construction methods.
We should also establish a common base class that can be parametize to have
CDO or Temporality or (Temporality and CDO). Ideally it should also handle
Teneo however I don't know much about the base class used in Teneo.
Thoughts?
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fnfdmu$105$1@build.eclipse.org...
Eike,
Comments below.
Eike Stepper wrote:
Hi Jean-Claude,
Comments below...
jc schrieb:
Hi,
I would like to open a discussion on the topic of sharing hook points into
the EStore and the Root extends class.
As you may already know if two features say CDO and Temporality are to be
used simultaneously we need to agree on a way to chain EStores.
Also we need figure out what to do about the Root extends class.
I believe Temporality could be all implemented from an EStore as long as the
following events are added to the EStore interface.
- creation event (the EObject is being instantiated.)
The EStore interface has a
public EObject create(EClass eClass);
But I could never figure out who/what/when is expected to call it. My store
implementation just throws an UOE. If an EStore represents some sort of
persistence container that is associated with a set of *persistent* objects
(i.e. a Resource or a ResourceSet) then I believe that object creation
always occurs outside of this container in a first stage, i.e. object
creation is always a *transient* operation. These transient objects can only
become persistent when they are added to containment references of objects
that are already persistent. With CDO the persistent root objects are the
Resources themselves (which really implement EObject!).
So I even don't have an idea what the semantics of EStore.create(EClass)
should be.
This is one of the problems of defining an API without the direct
interaction with the associated users of the API. Given that a factory
typically creates things, it wasn't entirely obvious to me how this ought to
be used and given that it doesn't make so much sense for the shared factory
to be associated with only one store, it doesn't seem terribly useful. Note
that data graphs and data objects have create methods and that the APIs were
designed to support folks who were implementing some lazy SDO stuff, so
likely they hooked the data graph to a store could funnel all creation to
that store.
- get/set containment
It is possible to derive these events from other events
(set/unset/add/remove) in combination with knowledge about the underlying
model (containment references). This is also the way CDO implements EStore.
Yes, change in containers is implicit in changes to containment references.
Here's a document sketching out a possible solution for delegating EStores:
http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
Here's a description of the Temporality project:
http://www.eclipse.org/modeling/emft/?project=temporality
Eike already opened a bug regarding the issue of delegating EStores:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
I will have a look at the CDO implementation to get a better understanding
of how it hooks itself in EMF.
You should start with the classes CDOObjectImpl, CDOStore and
CDOStateMachine.
Please ask me if you need assistance ;-)
I think Eike's done a great job building a meaningful implementation around
these APIs. It's interesting how he's got it set up to use a dynamic type
of implementation to back the data until the object becomes associated with
a store and at that point the data is transferred over. Very innovative...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #110641 is a reply to message #110500] |
Wed, 30 January 2008 15:46 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi JC,
I think there are two intersting areas where we could contribute to EMF:
1) Provide a subclass of EStoreEObjectImpl that can delegate to
different EStore implementations so that the user/developer doesn't need
to exclusively choose in the genmodel. I must add that I see
degradations in performance and memory usage when I have to pull my
additional object state out of adapters...
2) Provide a stateless implementation of EStore that factors out the
handling of attach/detach due to containment references.
IMHO these areas are not depending on each other.
Is that what you propose?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
jc schrieb:
> Hi Eike,
>
> As I suspected you have the same hooks in your CDOObjectImpl base class
> (Root Implements Class) as I do in my base class TemporalBaseEObjectImpl.
>
> That is you trap getting/setting the container and creation.
>
>
> creation
> ========
>
> private static final ContextTracer TRACER = new
> ContextTracer(OM.DEBUG_OBJECT, CDOObjectImpl.class);
>
> public CDOObjectImpl()
> {
> state = CDOState.TRANSIENT;
> eContainer = null;
> }
>
> no caching
> ==========
> /**
> * Don't cache non-transient features in this CDOObject's {@link
> #eSettings()}.
> */
> @Override
> protected boolean eIsCaching()
> {
> return false;
> }
>
>
> getting/setting container
> =========================
> public InternalEObject eInternalContainer()
> { ...
> // Delegate to CDOStore
> container = getStore().getContainer(this);
>
>
> protected void eBasicSetContainer(InternalEObject newContainer, int
> newContainerFeatureID)
> { ...
> // Delegate to CDOStore
> getStore().setContainer(this, newContainer, newContainerFeatureID);
>
>
>
> In CDOStore you added a setContainer method, in here you pass the request to
> the correct version:
>
> public void setContainer(InternalEObject eObject, InternalEObject
> newContainer, int newContainerFeatureID)
> {
> InternalCDOObject cdoObject = getCDOObject(eObject);
> if (TRACER.isEnabled())
> {
> TRACER.format("setContainer({0}, {1}, {2})", cdoObject, newContainer,
> newContainerFeatureID);
> }
>
> CDOID containerID =
> (CDOID)((CDOViewImpl)cdoObject.cdoView()).convertObjectToID( newContainer);
>
> CDOFeatureDelta delta = new CDOContainerFeatureDeltaImpl(containerID,
> newContainerFeatureID);
> InternalCDORevision revision = getRevisionForWriting(cdoObject, delta);
> revision.setContainerID(containerID);
> revision.setContainingFeatureID(newContainerFeatureID);
> }
>
> public InternalEObject getContainer(InternalEObject eObject)
> {
> InternalCDOObject cdoObject = getCDOObject(eObject);
> if (TRACER.isEnabled())
> {
> TRACER.format("getContainer({0})", cdoObject);
> }
>
> InternalCDORevision revision = getRevisionForReading(cdoObject);
> CDOID id = revision.getContainerID();
> return
> (InternalEObject)((CDOViewImpl)cdoObject.cdoView()).convertI DToObject(id);
> }
>
>
> I did the same thing in TemporalBaseEObjectImpl, except that I'm not passing
> it to my EStore however I could have. But the idea is the same. I trap
> containment getting and setting and handle them.
>
> creation
> ========
> public TemporalBaseEObjectImpl(EClass eClass) {
> super(eClass, new TemporalEStoreImpl(new EStoreEObjectImpl.EStoreImpl()));
> TemporalUtil.initTemporal(this);
> }
>
> no caching
> ==========
> /**
> * Overriden to prevent base class from caching the values returned from
> the EStore.
> * We want to be able to control the retrieval of data through the getters.
> */
> protected boolean eIsCaching(){
> return false;
> }
>
> getting/setting container
> =========================
> /**
> * JCC: added this to support versioning of containment features.
> * To version the containment reference we need to hook into the setter for
> it.
> * This method is overriden to give us access to the setting of the
> containment reference.
> * What this method does is try to find a version to delegate this setter
> to. If a version
> * is found it delegates the setter to it. If this is the version on which
> it should be
> * performed it does not delegate (it passes the request to its base class).
> */
> public NotificationChain eBasicSetContainer(InternalEObject newContainer,
> int newContainerFeatureID,
> NotificationChain msgs) {
>
> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
> InternalEObject version =
> TemporalEStoreHandler.findVersionToDelegateMutatorTo(this, null);
> if (version != null) {
> return version.eBasicSetContainer(newContainer, newContainerFeatureID,
> msgs);
> }
> }
> return super.eBasicSetContainer(newContainer, newContainerFeatureID, msgs);
> }
>
> /**
> * JCC: added this to support versioning of containment features.
> * To version the containment reference we need to hook into the getter for
> it.
> * This method is overriden to give us access to the getter of the
> containment reference.
> * What this method does is try to find a version to delegate this getter
> to. If a version
> * is found it delegates the getter to it. If this is the version on which
> it should be
> * performed it does not delegate (it passes the request to its base class).
> */
> public InternalEObject eInternalContainer() {
> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
> InternalEObject version =
> TemporalEStoreHandler.findVersionToDelegateAccessorTo(this, null);
> if (version != null) {
> return version.eInternalContainer();
> }
> }
> return super.eInternalContainer();
> }
>
>
>
>
> Since we have the same requirements we should try to come up with a new
> EStore interface with the added setContainer and construction methods.
>
> We should also establish a common base class that can be parametize to have
> CDO or Temporality or (Temporality and CDO). Ideally it should also handle
> Teneo however I don't know much about the base class used in Teneo.
>
> Thoughts?
>
>
>
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fnfdmu$105$1@build.eclipse.org...
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
> Hi Jean-Claude,
>
> Comments below...
>
>
> jc schrieb:
> Hi,
>
> I would like to open a discussion on the topic of sharing hook points into
> the EStore and the Root extends class.
>
> As you may already know if two features say CDO and Temporality are to be
> used simultaneously we need to agree on a way to chain EStores.
>
> Also we need figure out what to do about the Root extends class.
>
> I believe Temporality could be all implemented from an EStore as long as the
> following events are added to the EStore interface.
> - creation event (the EObject is being instantiated.)
>
> The EStore interface has a
>
> public EObject create(EClass eClass);
>
>
> But I could never figure out who/what/when is expected to call it. My store
> implementation just throws an UOE. If an EStore represents some sort of
> persistence container that is associated with a set of *persistent* objects
> (i.e. a Resource or a ResourceSet) then I believe that object creation
> always occurs outside of this container in a first stage, i.e. object
> creation is always a *transient* operation. These transient objects can only
> become persistent when they are added to containment references of objects
> that are already persistent. With CDO the persistent root objects are the
> Resources themselves (which really implement EObject!).
>
> So I even don't have an idea what the semantics of EStore.create(EClass)
> should be.
>
> This is one of the problems of defining an API without the direct
> interaction with the associated users of the API. Given that a factory
> typically creates things, it wasn't entirely obvious to me how this ought to
> be used and given that it doesn't make so much sense for the shared factory
> to be associated with only one store, it doesn't seem terribly useful. Note
> that data graphs and data objects have create methods and that the APIs were
> designed to support folks who were implementing some lazy SDO stuff, so
> likely they hooked the data graph to a store could funnel all creation to
> that store.
>
>
>
> - get/set containment
>
> It is possible to derive these events from other events
> (set/unset/add/remove) in combination with knowledge about the underlying
> model (containment references). This is also the way CDO implements EStore.
>
> Yes, change in containers is implicit in changes to containment references.
>
>
>
> Here's a document sketching out a possible solution for delegating EStores:
> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>
> Here's a description of the Temporality project:
> http://www.eclipse.org/modeling/emft/?project=temporality
>
> Eike already opened a bug regarding the issue of delegating EStores:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>
> I will have a look at the CDO implementation to get a better understanding
> of how it hooks itself in EMF.
>
> You should start with the classes CDOObjectImpl, CDOStore and
> CDOStateMachine.
> Please ask me if you need assistance ;-)
>
> I think Eike's done a great job building a meaningful implementation around
> these APIs. It's interesting how he's got it set up to use a dynamic type
> of implementation to back the data until the object becomes associated with
> a store and at that point the data is transferred over. Very innovative...
>
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #111913 is a reply to message #110641] |
Fri, 08 February 2008 14:17 |
Jean-Claude Cote
Messages: 56
Registered: July 2009 |
Member |
|
|
Essentially yes.
I think both of these strategies are missing and would be an asset to EMF.
"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fnq658$qa8$17@build.eclipse.org...
> Hi JC,
>
> I think there are two intersting areas where we could contribute to EMF:
> 1) Provide a subclass of EStoreEObjectImpl that can delegate to different
> EStore implementations so that the user/developer doesn't need to
> exclusively choose in the genmodel. I must add that I see degradations in
> performance and memory usage when I have to pull my additional object
> state out of adapters...
> 2) Provide a stateless implementation of EStore that factors out the
> handling of attach/detach due to containment references.
>
> IMHO these areas are not depending on each other.
> Is that what you propose?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
> jc schrieb:
>> Hi Eike,
>>
>> As I suspected you have the same hooks in your CDOObjectImpl base class
>> (Root Implements Class) as I do in my base class TemporalBaseEObjectImpl.
>>
>> That is you trap getting/setting the container and creation.
>>
>>
>> creation
>> ========
>>
>> private static final ContextTracer TRACER = new
>> ContextTracer(OM.DEBUG_OBJECT, CDOObjectImpl.class);
>>
>> public CDOObjectImpl()
>> {
>> state = CDOState.TRANSIENT;
>> eContainer = null;
>> }
>>
>> no caching
>> ==========
>> /**
>> * Don't cache non-transient features in this CDOObject's {@link
>> #eSettings()}.
>> */
>> @Override
>> protected boolean eIsCaching()
>> {
>> return false;
>> }
>>
>>
>> getting/setting container
>> =========================
>> public InternalEObject eInternalContainer()
>> { ...
>> // Delegate to CDOStore
>> container = getStore().getContainer(this);
>>
>>
>> protected void eBasicSetContainer(InternalEObject newContainer, int
>> newContainerFeatureID)
>> { ...
>> // Delegate to CDOStore
>> getStore().setContainer(this, newContainer, newContainerFeatureID);
>>
>>
>>
>> In CDOStore you added a setContainer method, in here you pass the request
>> to the correct version:
>>
>> public void setContainer(InternalEObject eObject, InternalEObject
>> newContainer, int newContainerFeatureID)
>> {
>> InternalCDOObject cdoObject = getCDOObject(eObject);
>> if (TRACER.isEnabled())
>> {
>> TRACER.format("setContainer({0}, {1}, {2})", cdoObject,
>> newContainer, newContainerFeatureID);
>> }
>>
>> CDOID containerID =
>> (CDOID)((CDOViewImpl)cdoObject.cdoView()).convertObjectToID( newContainer);
>>
>> CDOFeatureDelta delta = new CDOContainerFeatureDeltaImpl(containerID,
>> newContainerFeatureID);
>> InternalCDORevision revision = getRevisionForWriting(cdoObject,
>> delta);
>> revision.setContainerID(containerID);
>> revision.setContainingFeatureID(newContainerFeatureID);
>> }
>>
>> public InternalEObject getContainer(InternalEObject eObject)
>> {
>> InternalCDOObject cdoObject = getCDOObject(eObject);
>> if (TRACER.isEnabled())
>> {
>> TRACER.format("getContainer({0})", cdoObject);
>> }
>>
>> InternalCDORevision revision = getRevisionForReading(cdoObject);
>> CDOID id = revision.getContainerID();
>> return
>> (InternalEObject)((CDOViewImpl)cdoObject.cdoView()).convertI DToObject(id);
>> }
>>
>>
>> I did the same thing in TemporalBaseEObjectImpl, except that I'm not
>> passing it to my EStore however I could have. But the idea is the same. I
>> trap containment getting and setting and handle them.
>>
>> creation
>> ========
>> public TemporalBaseEObjectImpl(EClass eClass) {
>> super(eClass, new TemporalEStoreImpl(new
>> EStoreEObjectImpl.EStoreImpl()));
>> TemporalUtil.initTemporal(this);
>> }
>>
>> no caching
>> ==========
>> /**
>> * Overriden to prevent base class from caching the values returned from
>> the EStore.
>> * We want to be able to control the retrieval of data through the
>> getters.
>> */
>> protected boolean eIsCaching(){
>> return false;
>> }
>>
>> getting/setting container
>> =========================
>> /**
>> * JCC: added this to support versioning of containment features.
>> * To version the containment reference we need to hook into the setter
>> for it.
>> * This method is overriden to give us access to the setting of the
>> containment reference.
>> * What this method does is try to find a version to delegate this setter
>> to. If a version
>> * is found it delegates the setter to it. If this is the version on
>> which it should be
>> * performed it does not delegate (it passes the request to its base
>> class).
>> */
>> public NotificationChain eBasicSetContainer(InternalEObject newContainer,
>> int newContainerFeatureID,
>> NotificationChain msgs) {
>>
>> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
>> InternalEObject version =
>> TemporalEStoreHandler.findVersionToDelegateMutatorTo(this, null);
>> if (version != null) {
>> return version.eBasicSetContainer(newContainer, newContainerFeatureID,
>> msgs);
>> }
>> }
>> return super.eBasicSetContainer(newContainer, newContainerFeatureID,
>> msgs);
>> }
>>
>> /**
>> * JCC: added this to support versioning of containment features.
>> * To version the containment reference we need to hook into the getter
>> for it.
>> * This method is overriden to give us access to the getter of the
>> containment reference.
>> * What this method does is try to find a version to delegate this getter
>> to. If a version
>> * is found it delegates the getter to it. If this is the version on
>> which it should be
>> * performed it does not delegate (it passes the request to its base
>> class).
>> */
>> public InternalEObject eInternalContainer() {
>> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
>> InternalEObject version =
>> TemporalEStoreHandler.findVersionToDelegateAccessorTo(this, null);
>> if (version != null) {
>> return version.eInternalContainer();
>> }
>> }
>> return super.eInternalContainer();
>> }
>>
>>
>>
>>
>> Since we have the same requirements we should try to come up with a new
>> EStore interface with the added setContainer and construction methods.
>>
>> We should also establish a common base class that can be parametize to
>> have CDO or Temporality or (Temporality and CDO). Ideally it should also
>> handle Teneo however I don't know much about the base class used in
>> Teneo.
>>
>> Thoughts?
>>
>>
>>
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:fnfdmu$105$1@build.eclipse.org...
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>> Hi Jean-Claude,
>>
>> Comments below...
>>
>>
>> jc schrieb:
>> Hi,
>>
>> I would like to open a discussion on the topic of sharing hook points
>> into
>> the EStore and the Root extends class.
>>
>> As you may already know if two features say CDO and Temporality are to be
>> used simultaneously we need to agree on a way to chain EStores.
>>
>> Also we need figure out what to do about the Root extends class.
>>
>> I believe Temporality could be all implemented from an EStore as long as
>> the
>> following events are added to the EStore interface.
>> - creation event (the EObject is being instantiated.)
>>
>> The EStore interface has a
>>
>> public EObject create(EClass eClass);
>>
>>
>> But I could never figure out who/what/when is expected to call it. My
>> store implementation just throws an UOE. If an EStore represents some
>> sort of persistence container that is associated with a set of
>> *persistent* objects (i.e. a Resource or a ResourceSet) then I believe
>> that object creation always occurs outside of this container in a first
>> stage, i.e. object creation is always a *transient* operation. These
>> transient objects can only become persistent when they are added to
>> containment references of objects that are already persistent. With CDO
>> the persistent root objects are the Resources themselves (which really
>> implement EObject!).
>>
>> So I even don't have an idea what the semantics of EStore.create(EClass)
>> should be.
>>
>> This is one of the problems of defining an API without the direct
>> interaction with the associated users of the API. Given that a factory
>> typically creates things, it wasn't entirely obvious to me how this ought
>> to be used and given that it doesn't make so much sense for the shared
>> factory to be associated with only one store, it doesn't seem terribly
>> useful. Note that data graphs and data objects have create methods and
>> that the APIs were designed to support folks who were implementing some
>> lazy SDO stuff, so likely they hooked the data graph to a store could
>> funnel all creation to that store.
>>
>>
>>
>> - get/set containment
>>
>> It is possible to derive these events from other events
>> (set/unset/add/remove) in combination with knowledge about the underlying
>> model (containment references). This is also the way CDO implements
>> EStore.
>>
>> Yes, change in containers is implicit in changes to containment
>> references.
>>
>>
>>
>> Here's a document sketching out a possible solution for delegating
>> EStores:
>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>
>> Here's a description of the Temporality project:
>> http://www.eclipse.org/modeling/emft/?project=temporality
>>
>> Eike already opened a bug regarding the issue of delegating EStores:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>>
>> I will have a look at the CDO implementation to get a better
>> understanding
>> of how it hooks itself in EMF.
>>
>> You should start with the classes CDOObjectImpl, CDOStore and
>> CDOStateMachine.
>> Please ask me if you need assistance ;-)
>>
>> I think Eike's done a great job building a meaningful implementation
>> around these APIs. It's interesting how he's got it set up to use a
>> dynamic type of implementation to back the data until the object becomes
>> associated with a store and at that point the data is transferred over.
>> Very innovative...
>>
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #111914 is a reply to message #108620] |
Fri, 08 February 2008 15:10 |
|
Hi Simon,
CDOObjectImpl doesn't use the field
org.eclipse.emf.ecore.impl.EStoreEObjectImpl.eStore and it hopes that this
field gets removed (moved to a subclass). I think there's a Bugzilla for
this somewhere...
CDOObjectImpl uses the following approach:
private CDOStore getStore()
{
return cdoView().getStore();
}
I think the main problem with combining Jean-Claudes' and my framework is
the fact that you can only specify one class name in the genmodel for
"Root Extends Class". And of course an instance can have only one class
;-) Either solution for a more cooperative behaviour would have a negative
impact on footprint and performance...
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #614092 is a reply to message #108304] |
Sat, 26 January 2008 09:33 |
|
This is a multi-part message in MIME format.
--------------050303060002020302090607
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Jean-Claude,
Comments below...
jc schrieb:
> Hi,
>
> I would like to open a discussion on the topic of sharing hook points into
> the EStore and the Root extends class.
>
> As you may already know if two features say CDO and Temporality are to be
> used simultaneously we need to agree on a way to chain EStores.
>
> Also we need figure out what to do about the Root extends class.
>
> I believe Temporality could be all implemented from an EStore as long as the
> following events are added to the EStore interface.
> - creation event (the EObject is being instantiated.)
>
The EStore interface has a
| *public *EObject create(EClass eClass);|
But I could never figure out who/what/when is expected to call it. My
store implementation just throws an UOE. If an EStore represents some
sort of persistence container that is associated with a set of
*persistent* objects (i.e. a Resource or a ResourceSet) then I believe
that object creation always occurs outside of this container in a first
stage, i.e. object creation is always a *transient* operation. These
transient objects can only become persistent when they are added to
containment references of objects that are already persistent. With CDO
the persistent root objects are the Resources themselves (which really
implement EObject!).
So I even don't have an idea what the semantics of EStore.create(EClass)
should be.
> - get/set containment
>
It is possible to derive these events from other events
(set/unset/add/remove) in combination with knowledge about the
underlying model (containment references). This is also the way CDO
implements EStore.
> Here's a document sketching out a possible solution for delegating EStores:
> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>
> Here's a description of the Temporality project:
> http://www.eclipse.org/modeling/emft/?project=temporality
>
> Eike already opened a bug regarding the issue of delegating EStores:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>
> I will have a look at the CDO implementation to get a better understanding
> of how it hooks itself in EMF.
>
You should start with the classes CDOObjectImpl, CDOStore and
CDOStateMachine.
Please ask me if you need assistance ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
--------------050303060002020302090607
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">
Hi Jean-Claude,<br>
<br>
Comments below...<br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fndkc0$rfp$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
I would like to open a discussion on the topic of sharing hook points into
the EStore and the Root extends class.
As you may already know if two features say CDO and Temporality are to be
used simultaneously we need to agree on a way to chain EStores.
Also we need figure out what to do about the Root extends class.
I believe Temporality could be all implemented from an EStore as long as the
following events are added to the EStore interface.
- creation event (the EObject is being instantiated.)
</pre>
</blockquote>
The EStore interface has a <br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #614096 is a reply to message #108326] |
Sat, 26 January 2008 13:48 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090402000707010705080207
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Comments below.
Eike Stepper wrote:
> Hi Jean-Claude,
>
> Comments below...
>
>
> jc schrieb:
>> Hi,
>>
>> I would like to open a discussion on the topic of sharing hook points into
>> the EStore and the Root extends class.
>>
>> As you may already know if two features say CDO and Temporality are to be
>> used simultaneously we need to agree on a way to chain EStores.
>>
>> Also we need figure out what to do about the Root extends class.
>>
>> I believe Temporality could be all implemented from an EStore as long as the
>> following events are added to the EStore interface.
>> - creation event (the EObject is being instantiated.)
>>
> The EStore interface has a
> | *public *EObject create(EClass eClass);|
>
>
> But I could never figure out who/what/when is expected to call it. My
> store implementation just throws an UOE. If an EStore represents some
> sort of persistence container that is associated with a set of
> *persistent* objects (i.e. a Resource or a ResourceSet) then I believe
> that object creation always occurs outside of this container in a
> first stage, i.e. object creation is always a *transient* operation.
> These transient objects can only become persistent when they are added
> to containment references of objects that are already persistent. With
> CDO the persistent root objects are the Resources themselves (which
> really implement EObject!).
>
> So I even don't have an idea what the semantics of
> EStore.create(EClass) should be.
This is one of the problems of defining an API without the direct
interaction with the associated users of the API. Given that a factory
typically creates things, it wasn't entirely obvious to me how this
ought to be used and given that it doesn't make so much sense for the
shared factory to be associated with only one store, it doesn't seem
terribly useful. Note that data graphs and data objects have create
methods and that the APIs were designed to support folks who were
implementing some lazy SDO stuff, so likely they hooked the data graph
to a store could funnel all creation to that store.
>
>> - get/set containment
>>
> It is possible to derive these events from other events
> (set/unset/add/remove) in combination with knowledge about the
> underlying model (containment references). This is also the way CDO
> implements EStore.
Yes, change in containers is implicit in changes to containment references.
>
>> Here's a document sketching out a possible solution for delegating EStores:
>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>
>> Here's a description of the Temporality project:
>> http://www.eclipse.org/modeling/emft/?project=temporality
>>
>> Eike already opened a bug regarding the issue of delegating EStores:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>>
>> I will have a look at the CDO implementation to get a better understanding
>> of how it hooks itself in EMF.
>>
> You should start with the classes CDOObjectImpl, CDOStore and
> CDOStateMachine.
> Please ask me if you need assistance ;-)
I think Eike's done a great job building a meaningful implementation
around these APIs. It's interesting how he's got it set up to use a
dynamic type of implementation to back the data until the object becomes
associated with a store and at that point the data is transferred over.
Very innovative...
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
--------------090402000707010705080207
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">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fneupe$5ft$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
Hi Jean-Claude,<br>
<br>
Comments below...<br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fndkc0$rfp$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
I would like to open a discussion on the topic of sharing hook points into
the EStore and the Root extends class.
As you may already know if two features say CDO and Temporality are to be
used simultaneously we need to agree on a way to chain EStores.
Also we need figure out what to do about the Root extends class.
I believe Temporality could be all implemented from an EStore as long as the
following events are added to the EStore interface.
- creation event (the EObject is being instantiated.)
</pre>
</blockquote>
The EStore interface has a <br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; ">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = --><!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #614345 is a reply to message #108388] |
Wed, 30 January 2008 15:05 |
Jean-Claude Cote
Messages: 56
Registered: July 2009 |
Member |
|
|
Hi Eike,
As I suspected you have the same hooks in your CDOObjectImpl base class
(Root Implements Class) as I do in my base class TemporalBaseEObjectImpl.
That is you trap getting/setting the container and creation.
creation
========
private static final ContextTracer TRACER = new
ContextTracer(OM.DEBUG_OBJECT, CDOObjectImpl.class);
public CDOObjectImpl()
{
state = CDOState.TRANSIENT;
eContainer = null;
}
no caching
==========
/**
* Don't cache non-transient features in this CDOObject's {@link
#eSettings()}.
*/
@Override
protected boolean eIsCaching()
{
return false;
}
getting/setting container
=========================
public InternalEObject eInternalContainer()
{ ...
// Delegate to CDOStore
container = getStore().getContainer(this);
protected void eBasicSetContainer(InternalEObject newContainer, int
newContainerFeatureID)
{ ...
// Delegate to CDOStore
getStore().setContainer(this, newContainer, newContainerFeatureID);
In CDOStore you added a setContainer method, in here you pass the request to
the correct version:
public void setContainer(InternalEObject eObject, InternalEObject
newContainer, int newContainerFeatureID)
{
InternalCDOObject cdoObject = getCDOObject(eObject);
if (TRACER.isEnabled())
{
TRACER.format("setContainer({0}, {1}, {2})", cdoObject, newContainer,
newContainerFeatureID);
}
CDOID containerID =
(CDOID)((CDOViewImpl)cdoObject.cdoView()).convertObjectToID( newContainer);
CDOFeatureDelta delta = new CDOContainerFeatureDeltaImpl(containerID,
newContainerFeatureID);
InternalCDORevision revision = getRevisionForWriting(cdoObject, delta);
revision.setContainerID(containerID);
revision.setContainingFeatureID(newContainerFeatureID);
}
public InternalEObject getContainer(InternalEObject eObject)
{
InternalCDOObject cdoObject = getCDOObject(eObject);
if (TRACER.isEnabled())
{
TRACER.format("getContainer({0})", cdoObject);
}
InternalCDORevision revision = getRevisionForReading(cdoObject);
CDOID id = revision.getContainerID();
return
(InternalEObject)((CDOViewImpl)cdoObject.cdoView()).convertI DToObject(id);
}
I did the same thing in TemporalBaseEObjectImpl, except that I'm not passing
it to my EStore however I could have. But the idea is the same. I trap
containment getting and setting and handle them.
creation
========
public TemporalBaseEObjectImpl(EClass eClass) {
super(eClass, new TemporalEStoreImpl(new EStoreEObjectImpl.EStoreImpl()));
TemporalUtil.initTemporal(this);
}
no caching
==========
/**
* Overriden to prevent base class from caching the values returned from
the EStore.
* We want to be able to control the retrieval of data through the getters.
*/
protected boolean eIsCaching(){
return false;
}
getting/setting container
=========================
/**
* JCC: added this to support versioning of containment features.
* To version the containment reference we need to hook into the setter for
it.
* This method is overriden to give us access to the setting of the
containment reference.
* What this method does is try to find a version to delegate this setter
to. If a version
* is found it delegates the setter to it. If this is the version on which
it should be
* performed it does not delegate (it passes the request to its base class).
*/
public NotificationChain eBasicSetContainer(InternalEObject newContainer,
int newContainerFeatureID,
NotificationChain msgs) {
if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
InternalEObject version =
TemporalEStoreHandler.findVersionToDelegateMutatorTo(this, null);
if (version != null) {
return version.eBasicSetContainer(newContainer, newContainerFeatureID,
msgs);
}
}
return super.eBasicSetContainer(newContainer, newContainerFeatureID, msgs);
}
/**
* JCC: added this to support versioning of containment features.
* To version the containment reference we need to hook into the getter for
it.
* This method is overriden to give us access to the getter of the
containment reference.
* What this method does is try to find a version to delegate this getter
to. If a version
* is found it delegates the getter to it. If this is the version on which
it should be
* performed it does not delegate (it passes the request to its base class).
*/
public InternalEObject eInternalContainer() {
if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
InternalEObject version =
TemporalEStoreHandler.findVersionToDelegateAccessorTo(this, null);
if (version != null) {
return version.eInternalContainer();
}
}
return super.eInternalContainer();
}
Since we have the same requirements we should try to come up with a new
EStore interface with the added setContainer and construction methods.
We should also establish a common base class that can be parametize to have
CDO or Temporality or (Temporality and CDO). Ideally it should also handle
Teneo however I don't know much about the base class used in Teneo.
Thoughts?
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fnfdmu$105$1@build.eclipse.org...
Eike,
Comments below.
Eike Stepper wrote:
Hi Jean-Claude,
Comments below...
jc schrieb:
Hi,
I would like to open a discussion on the topic of sharing hook points into
the EStore and the Root extends class.
As you may already know if two features say CDO and Temporality are to be
used simultaneously we need to agree on a way to chain EStores.
Also we need figure out what to do about the Root extends class.
I believe Temporality could be all implemented from an EStore as long as the
following events are added to the EStore interface.
- creation event (the EObject is being instantiated.)
The EStore interface has a
public EObject create(EClass eClass);
But I could never figure out who/what/when is expected to call it. My store
implementation just throws an UOE. If an EStore represents some sort of
persistence container that is associated with a set of *persistent* objects
(i.e. a Resource or a ResourceSet) then I believe that object creation
always occurs outside of this container in a first stage, i.e. object
creation is always a *transient* operation. These transient objects can only
become persistent when they are added to containment references of objects
that are already persistent. With CDO the persistent root objects are the
Resources themselves (which really implement EObject!).
So I even don't have an idea what the semantics of EStore.create(EClass)
should be.
This is one of the problems of defining an API without the direct
interaction with the associated users of the API. Given that a factory
typically creates things, it wasn't entirely obvious to me how this ought to
be used and given that it doesn't make so much sense for the shared factory
to be associated with only one store, it doesn't seem terribly useful. Note
that data graphs and data objects have create methods and that the APIs were
designed to support folks who were implementing some lazy SDO stuff, so
likely they hooked the data graph to a store could funnel all creation to
that store.
- get/set containment
It is possible to derive these events from other events
(set/unset/add/remove) in combination with knowledge about the underlying
model (containment references). This is also the way CDO implements EStore.
Yes, change in containers is implicit in changes to containment references.
Here's a document sketching out a possible solution for delegating EStores:
http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
Here's a description of the Temporality project:
http://www.eclipse.org/modeling/emft/?project=temporality
Eike already opened a bug regarding the issue of delegating EStores:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
I will have a look at the CDO implementation to get a better understanding
of how it hooks itself in EMF.
You should start with the classes CDOObjectImpl, CDOStore and
CDOStateMachine.
Please ask me if you need assistance ;-)
I think Eike's done a great job building a meaningful implementation around
these APIs. It's interesting how he's got it set up to use a dynamic type
of implementation to back the data until the object becomes associated with
a store and at that point the data is transferred over. Very innovative...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #614347 is a reply to message #110500] |
Wed, 30 January 2008 15:46 |
|
Hi JC,
I think there are two intersting areas where we could contribute to EMF:
1) Provide a subclass of EStoreEObjectImpl that can delegate to
different EStore implementations so that the user/developer doesn't need
to exclusively choose in the genmodel. I must add that I see
degradations in performance and memory usage when I have to pull my
additional object state out of adapters...
2) Provide a stateless implementation of EStore that factors out the
handling of attach/detach due to containment references.
IMHO these areas are not depending on each other.
Is that what you propose?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
jc schrieb:
> Hi Eike,
>
> As I suspected you have the same hooks in your CDOObjectImpl base class
> (Root Implements Class) as I do in my base class TemporalBaseEObjectImpl.
>
> That is you trap getting/setting the container and creation.
>
>
> creation
> ========
>
> private static final ContextTracer TRACER = new
> ContextTracer(OM.DEBUG_OBJECT, CDOObjectImpl.class);
>
> public CDOObjectImpl()
> {
> state = CDOState.TRANSIENT;
> eContainer = null;
> }
>
> no caching
> ==========
> /**
> * Don't cache non-transient features in this CDOObject's {@link
> #eSettings()}.
> */
> @Override
> protected boolean eIsCaching()
> {
> return false;
> }
>
>
> getting/setting container
> =========================
> public InternalEObject eInternalContainer()
> { ...
> // Delegate to CDOStore
> container = getStore().getContainer(this);
>
>
> protected void eBasicSetContainer(InternalEObject newContainer, int
> newContainerFeatureID)
> { ...
> // Delegate to CDOStore
> getStore().setContainer(this, newContainer, newContainerFeatureID);
>
>
>
> In CDOStore you added a setContainer method, in here you pass the request to
> the correct version:
>
> public void setContainer(InternalEObject eObject, InternalEObject
> newContainer, int newContainerFeatureID)
> {
> InternalCDOObject cdoObject = getCDOObject(eObject);
> if (TRACER.isEnabled())
> {
> TRACER.format("setContainer({0}, {1}, {2})", cdoObject, newContainer,
> newContainerFeatureID);
> }
>
> CDOID containerID =
> (CDOID)((CDOViewImpl)cdoObject.cdoView()).convertObjectToID( newContainer);
>
> CDOFeatureDelta delta = new CDOContainerFeatureDeltaImpl(containerID,
> newContainerFeatureID);
> InternalCDORevision revision = getRevisionForWriting(cdoObject, delta);
> revision.setContainerID(containerID);
> revision.setContainingFeatureID(newContainerFeatureID);
> }
>
> public InternalEObject getContainer(InternalEObject eObject)
> {
> InternalCDOObject cdoObject = getCDOObject(eObject);
> if (TRACER.isEnabled())
> {
> TRACER.format("getContainer({0})", cdoObject);
> }
>
> InternalCDORevision revision = getRevisionForReading(cdoObject);
> CDOID id = revision.getContainerID();
> return
> (InternalEObject)((CDOViewImpl)cdoObject.cdoView()).convertI DToObject(id);
> }
>
>
> I did the same thing in TemporalBaseEObjectImpl, except that I'm not passing
> it to my EStore however I could have. But the idea is the same. I trap
> containment getting and setting and handle them.
>
> creation
> ========
> public TemporalBaseEObjectImpl(EClass eClass) {
> super(eClass, new TemporalEStoreImpl(new EStoreEObjectImpl.EStoreImpl()));
> TemporalUtil.initTemporal(this);
> }
>
> no caching
> ==========
> /**
> * Overriden to prevent base class from caching the values returned from
> the EStore.
> * We want to be able to control the retrieval of data through the getters.
> */
> protected boolean eIsCaching(){
> return false;
> }
>
> getting/setting container
> =========================
> /**
> * JCC: added this to support versioning of containment features.
> * To version the containment reference we need to hook into the setter for
> it.
> * This method is overriden to give us access to the setting of the
> containment reference.
> * What this method does is try to find a version to delegate this setter
> to. If a version
> * is found it delegates the setter to it. If this is the version on which
> it should be
> * performed it does not delegate (it passes the request to its base class).
> */
> public NotificationChain eBasicSetContainer(InternalEObject newContainer,
> int newContainerFeatureID,
> NotificationChain msgs) {
>
> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
> InternalEObject version =
> TemporalEStoreHandler.findVersionToDelegateMutatorTo(this, null);
> if (version != null) {
> return version.eBasicSetContainer(newContainer, newContainerFeatureID,
> msgs);
> }
> }
> return super.eBasicSetContainer(newContainer, newContainerFeatureID, msgs);
> }
>
> /**
> * JCC: added this to support versioning of containment features.
> * To version the containment reference we need to hook into the getter for
> it.
> * This method is overriden to give us access to the getter of the
> containment reference.
> * What this method does is try to find a version to delegate this getter
> to. If a version
> * is found it delegates the getter to it. If this is the version on which
> it should be
> * performed it does not delegate (it passes the request to its base class).
> */
> public InternalEObject eInternalContainer() {
> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
> InternalEObject version =
> TemporalEStoreHandler.findVersionToDelegateAccessorTo(this, null);
> if (version != null) {
> return version.eInternalContainer();
> }
> }
> return super.eInternalContainer();
> }
>
>
>
>
> Since we have the same requirements we should try to come up with a new
> EStore interface with the added setContainer and construction methods.
>
> We should also establish a common base class that can be parametize to have
> CDO or Temporality or (Temporality and CDO). Ideally it should also handle
> Teneo however I don't know much about the base class used in Teneo.
>
> Thoughts?
>
>
>
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fnfdmu$105$1@build.eclipse.org...
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
> Hi Jean-Claude,
>
> Comments below...
>
>
> jc schrieb:
> Hi,
>
> I would like to open a discussion on the topic of sharing hook points into
> the EStore and the Root extends class.
>
> As you may already know if two features say CDO and Temporality are to be
> used simultaneously we need to agree on a way to chain EStores.
>
> Also we need figure out what to do about the Root extends class.
>
> I believe Temporality could be all implemented from an EStore as long as the
> following events are added to the EStore interface.
> - creation event (the EObject is being instantiated.)
>
> The EStore interface has a
>
> public EObject create(EClass eClass);
>
>
> But I could never figure out who/what/when is expected to call it. My store
> implementation just throws an UOE. If an EStore represents some sort of
> persistence container that is associated with a set of *persistent* objects
> (i.e. a Resource or a ResourceSet) then I believe that object creation
> always occurs outside of this container in a first stage, i.e. object
> creation is always a *transient* operation. These transient objects can only
> become persistent when they are added to containment references of objects
> that are already persistent. With CDO the persistent root objects are the
> Resources themselves (which really implement EObject!).
>
> So I even don't have an idea what the semantics of EStore.create(EClass)
> should be.
>
> This is one of the problems of defining an API without the direct
> interaction with the associated users of the API. Given that a factory
> typically creates things, it wasn't entirely obvious to me how this ought to
> be used and given that it doesn't make so much sense for the shared factory
> to be associated with only one store, it doesn't seem terribly useful. Note
> that data graphs and data objects have create methods and that the APIs were
> designed to support folks who were implementing some lazy SDO stuff, so
> likely they hooked the data graph to a store could funnel all creation to
> that store.
>
>
>
> - get/set containment
>
> It is possible to derive these events from other events
> (set/unset/add/remove) in combination with knowledge about the underlying
> model (containment references). This is also the way CDO implements EStore.
>
> Yes, change in containers is implicit in changes to containment references.
>
>
>
> Here's a document sketching out a possible solution for delegating EStores:
> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>
> Here's a description of the Temporality project:
> http://www.eclipse.org/modeling/emft/?project=temporality
>
> Eike already opened a bug regarding the issue of delegating EStores:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>
> I will have a look at the CDO implementation to get a better understanding
> of how it hooks itself in EMF.
>
> You should start with the classes CDOObjectImpl, CDOStore and
> CDOStateMachine.
> Please ask me if you need assistance ;-)
>
> I think Eike's done a great job building a meaningful implementation around
> these APIs. It's interesting how he's got it set up to use a dynamic type
> of implementation to back the data until the object becomes associated with
> a store and at that point the data is transferred over. Very innovative...
>
>
> 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][Teneo]Delegating EStore and Root extends class [message #615463 is a reply to message #110641] |
Fri, 08 February 2008 14:17 |
Jean-Claude Cote
Messages: 56
Registered: July 2009 |
Member |
|
|
Essentially yes.
I think both of these strategies are missing and would be an asset to EMF.
"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fnq658$qa8$17@build.eclipse.org...
> Hi JC,
>
> I think there are two intersting areas where we could contribute to EMF:
> 1) Provide a subclass of EStoreEObjectImpl that can delegate to different
> EStore implementations so that the user/developer doesn't need to
> exclusively choose in the genmodel. I must add that I see degradations in
> performance and memory usage when I have to pull my additional object
> state out of adapters...
> 2) Provide a stateless implementation of EStore that factors out the
> handling of attach/detach due to containment references.
>
> IMHO these areas are not depending on each other.
> Is that what you propose?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
> jc schrieb:
>> Hi Eike,
>>
>> As I suspected you have the same hooks in your CDOObjectImpl base class
>> (Root Implements Class) as I do in my base class TemporalBaseEObjectImpl.
>>
>> That is you trap getting/setting the container and creation.
>>
>>
>> creation
>> ========
>>
>> private static final ContextTracer TRACER = new
>> ContextTracer(OM.DEBUG_OBJECT, CDOObjectImpl.class);
>>
>> public CDOObjectImpl()
>> {
>> state = CDOState.TRANSIENT;
>> eContainer = null;
>> }
>>
>> no caching
>> ==========
>> /**
>> * Don't cache non-transient features in this CDOObject's {@link
>> #eSettings()}.
>> */
>> @Override
>> protected boolean eIsCaching()
>> {
>> return false;
>> }
>>
>>
>> getting/setting container
>> =========================
>> public InternalEObject eInternalContainer()
>> { ...
>> // Delegate to CDOStore
>> container = getStore().getContainer(this);
>>
>>
>> protected void eBasicSetContainer(InternalEObject newContainer, int
>> newContainerFeatureID)
>> { ...
>> // Delegate to CDOStore
>> getStore().setContainer(this, newContainer, newContainerFeatureID);
>>
>>
>>
>> In CDOStore you added a setContainer method, in here you pass the request
>> to the correct version:
>>
>> public void setContainer(InternalEObject eObject, InternalEObject
>> newContainer, int newContainerFeatureID)
>> {
>> InternalCDOObject cdoObject = getCDOObject(eObject);
>> if (TRACER.isEnabled())
>> {
>> TRACER.format("setContainer({0}, {1}, {2})", cdoObject,
>> newContainer, newContainerFeatureID);
>> }
>>
>> CDOID containerID =
>> (CDOID)((CDOViewImpl)cdoObject.cdoView()).convertObjectToID( newContainer);
>>
>> CDOFeatureDelta delta = new CDOContainerFeatureDeltaImpl(containerID,
>> newContainerFeatureID);
>> InternalCDORevision revision = getRevisionForWriting(cdoObject,
>> delta);
>> revision.setContainerID(containerID);
>> revision.setContainingFeatureID(newContainerFeatureID);
>> }
>>
>> public InternalEObject getContainer(InternalEObject eObject)
>> {
>> InternalCDOObject cdoObject = getCDOObject(eObject);
>> if (TRACER.isEnabled())
>> {
>> TRACER.format("getContainer({0})", cdoObject);
>> }
>>
>> InternalCDORevision revision = getRevisionForReading(cdoObject);
>> CDOID id = revision.getContainerID();
>> return
>> (InternalEObject)((CDOViewImpl)cdoObject.cdoView()).convertI DToObject(id);
>> }
>>
>>
>> I did the same thing in TemporalBaseEObjectImpl, except that I'm not
>> passing it to my EStore however I could have. But the idea is the same. I
>> trap containment getting and setting and handle them.
>>
>> creation
>> ========
>> public TemporalBaseEObjectImpl(EClass eClass) {
>> super(eClass, new TemporalEStoreImpl(new
>> EStoreEObjectImpl.EStoreImpl()));
>> TemporalUtil.initTemporal(this);
>> }
>>
>> no caching
>> ==========
>> /**
>> * Overriden to prevent base class from caching the values returned from
>> the EStore.
>> * We want to be able to control the retrieval of data through the
>> getters.
>> */
>> protected boolean eIsCaching(){
>> return false;
>> }
>>
>> getting/setting container
>> =========================
>> /**
>> * JCC: added this to support versioning of containment features.
>> * To version the containment reference we need to hook into the setter
>> for it.
>> * This method is overriden to give us access to the setting of the
>> containment reference.
>> * What this method does is try to find a version to delegate this setter
>> to. If a version
>> * is found it delegates the setter to it. If this is the version on
>> which it should be
>> * performed it does not delegate (it passes the request to its base
>> class).
>> */
>> public NotificationChain eBasicSetContainer(InternalEObject newContainer,
>> int newContainerFeatureID,
>> NotificationChain msgs) {
>>
>> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
>> InternalEObject version =
>> TemporalEStoreHandler.findVersionToDelegateMutatorTo(this, null);
>> if (version != null) {
>> return version.eBasicSetContainer(newContainer, newContainerFeatureID,
>> msgs);
>> }
>> }
>> return super.eBasicSetContainer(newContainer, newContainerFeatureID,
>> msgs);
>> }
>>
>> /**
>> * JCC: added this to support versioning of containment features.
>> * To version the containment reference we need to hook into the getter
>> for it.
>> * This method is overriden to give us access to the getter of the
>> containment reference.
>> * What this method does is try to find a version to delegate this getter
>> to. If a version
>> * is found it delegates the getter to it. If this is the version on
>> which it should be
>> * performed it does not delegate (it passes the request to its base
>> class).
>> */
>> public InternalEObject eInternalContainer() {
>> if (((TemporalEStoreImpl) this.eStore()).isBypass() == false) {
>> InternalEObject version =
>> TemporalEStoreHandler.findVersionToDelegateAccessorTo(this, null);
>> if (version != null) {
>> return version.eInternalContainer();
>> }
>> }
>> return super.eInternalContainer();
>> }
>>
>>
>>
>>
>> Since we have the same requirements we should try to come up with a new
>> EStore interface with the added setContainer and construction methods.
>>
>> We should also establish a common base class that can be parametize to
>> have CDO or Temporality or (Temporality and CDO). Ideally it should also
>> handle Teneo however I don't know much about the base class used in
>> Teneo.
>>
>> Thoughts?
>>
>>
>>
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:fnfdmu$105$1@build.eclipse.org...
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>> Hi Jean-Claude,
>>
>> Comments below...
>>
>>
>> jc schrieb:
>> Hi,
>>
>> I would like to open a discussion on the topic of sharing hook points
>> into
>> the EStore and the Root extends class.
>>
>> As you may already know if two features say CDO and Temporality are to be
>> used simultaneously we need to agree on a way to chain EStores.
>>
>> Also we need figure out what to do about the Root extends class.
>>
>> I believe Temporality could be all implemented from an EStore as long as
>> the
>> following events are added to the EStore interface.
>> - creation event (the EObject is being instantiated.)
>>
>> The EStore interface has a
>>
>> public EObject create(EClass eClass);
>>
>>
>> But I could never figure out who/what/when is expected to call it. My
>> store implementation just throws an UOE. If an EStore represents some
>> sort of persistence container that is associated with a set of
>> *persistent* objects (i.e. a Resource or a ResourceSet) then I believe
>> that object creation always occurs outside of this container in a first
>> stage, i.e. object creation is always a *transient* operation. These
>> transient objects can only become persistent when they are added to
>> containment references of objects that are already persistent. With CDO
>> the persistent root objects are the Resources themselves (which really
>> implement EObject!).
>>
>> So I even don't have an idea what the semantics of EStore.create(EClass)
>> should be.
>>
>> This is one of the problems of defining an API without the direct
>> interaction with the associated users of the API. Given that a factory
>> typically creates things, it wasn't entirely obvious to me how this ought
>> to be used and given that it doesn't make so much sense for the shared
>> factory to be associated with only one store, it doesn't seem terribly
>> useful. Note that data graphs and data objects have create methods and
>> that the APIs were designed to support folks who were implementing some
>> lazy SDO stuff, so likely they hooked the data graph to a store could
>> funnel all creation to that store.
>>
>>
>>
>> - get/set containment
>>
>> It is possible to derive these events from other events
>> (set/unset/add/remove) in combination with knowledge about the underlying
>> model (containment references). This is also the way CDO implements
>> EStore.
>>
>> Yes, change in containers is implicit in changes to containment
>> references.
>>
>>
>>
>> Here's a document sketching out a possible solution for delegating
>> EStores:
>> http://wiki.eclipse.org/images/a/ad/Delegatingestore.pdf
>>
>> Here's a description of the Temporality project:
>> http://www.eclipse.org/modeling/emft/?project=temporality
>>
>> Eike already opened a bug regarding the issue of delegating EStores:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=197487
>>
>> I will have a look at the CDO implementation to get a better
>> understanding
>> of how it hooks itself in EMF.
>>
>> You should start with the classes CDOObjectImpl, CDOStore and
>> CDOStateMachine.
>> Please ask me if you need assistance ;-)
>>
>> I think Eike's done a great job building a meaningful implementation
>> around these APIs. It's interesting how he's got it set up to use a
>> dynamic type of implementation to back the data until the object becomes
>> associated with a store and at that point the data is transferred over.
>> Very innovative...
>>
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
|
|
|
| Re: [Temporality][CDO][Teneo]Delegating EStore and Root extends class [message #615464 is a reply to message #108620] |
Fri, 08 February 2008 15:10 |
|
Hi Simon,
CDOObjectImpl doesn't use the field
org.eclipse.emf.ecore.impl.EStoreEObjectImpl.eStore and it hopes that this
field gets removed (moved to a subclass). I think there's a Bugzilla for
this somewhere...
CDOObjectImpl uses the following approach:
private CDOStore getStore()
{
return cdoView().getStore();
}
I think the main problem with combining Jean-Claudes' and my framework is
the fact that you can only specify one class name in the genmodel for
"Root Extends Class". And of course an instance can have only one class
;-) Either solution for a more cooperative behaviour would have a negative
impact on footprint and performance...
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:14:03 GMT 2024
Powered by FUDForum. Page generated in 0.03785 seconds |
] 
Search
Help
Register
Login
Home
