Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EStore: remove method is invoked right after an adding
EStore: remove method is invoked right after an adding [message #425508] Fri, 28 November 2008 13:38 Go to next message
Zoltan Balogh is currently offline Zoltan BaloghFriend
Messages: 9
Registered: July 2009
Junior Member
Hi All,

our simple goal is to persist EMF models in a separate store instead of
in memory (like in case of CDO), but we don’t need a complex solution
like CDO. In our case there are no dynamic objects (that are not
persisted yet) so we assume that every new object is first persisted in
the store and after that we can modify it. With this restriction we made
our implementation of InternalEObject extending the EStoreEObjectImpl
and write our own ESore implementation. With a minimal modification of
the generated editor we could test the implementation.

When we try to add a new child to an element, the store’s "add" method
is invoked and the adding is happened in our store. But right after that
the store’s "remove" method is also invoked with this new element and
it’s removed.

After debugging the addCommand it seems that during the adding process
the old container of the added element is being removed. The problem is
that the sore’s "add" method implicitly sets the container of the new
element so when the addCommand try to ask for the old container, this
will be the new one (because this is also delegating to the store’s
getContainer method).

I would like to ask that is that any simple solution to bridge this
difficulty without working with some kind of dynamic (transient) object?

It seems to me that the problem is that the EMF’s adding mechanism is
consists of some small atomic steps (e.g. add to list, remove the old
container, add new container, etc.) but the store works in little bit
higher level (e.g. add method) and there is no way to set the container
for example. Or maybe I missed something?

Thanks for Your help!
Zoli
Re: EStore: remove method is invoked right after an adding [message #425511 is a reply to message #425508] Fri, 28 November 2008 14:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30898
Registered: July 2009
Senior Member
Zoltan,

Comments below.


Zoltan Balogh wrote:
> Hi All,
>
> our simple goal is to persist EMF models in a separate store instead
> of in memory (like in case of CDO), but we don’t need a complex
> solution like CDO.
I've seen far more times that I can count when folks assume they can
build a simpler solution and instead end up with something different
that's just as complex...
> In our case there are no dynamic objects (that are not persisted yet)
> so we assume that every new object is first persisted in the store
Does "the store" imply an assumption that there is only one store?
> and after that we can modify it. With this restriction we made our
> implementation of InternalEObject extending the EStoreEObjectImpl and
> write our own ESore implementation. With a minimal modification of the
> generated editor we could test the implementation.
>
> When we try to add a new child to an element, the store’s "add" method
> is invoked and the adding is happened in our store. But right after
> that the store’s "remove" method is also invoked with this new element
> and it’s removed.
I'd assume some bidirectional handshaking is involved.
>
> After debugging the addCommand it seems that during the adding process
> the old container of the added element is being removed.
addCommand?
> The problem is that the sore’s "add" method implicitly sets the
> container of the new element so when the addCommand try to ask for the
> old container, this will be the new one (because this is also
> delegating to the store’s getContainer method).
I'm not sure how the add command is seeing an intermediate state. Al
the ends of the relationship should be updated at once.
>
> I would like to ask that is that any simple solution to bridge this
> difficulty without working with some kind of dynamic (transient) object?
>
> It seems to me that the problem is that the EMF’s adding mechanism is
> consists of some small atomic steps (e.g. add to list, remove the old
> container, add new container, etc.) but the store works in little bit
> higher level (e.g. add method) and there is no way to set the
> container for example. Or maybe I missed something?
For both the add and the remove calls to the store, the container is
provided in the call itself...

It would of course be interesting to look at how CDO deals with this. I
imagine that if you get a store remove call and the current container
isn't the first object (container object) given in the remove, that you
could assume you've been added to a different container already. If
they match, you could assume the container is becoming null.
>
> Thanks for Your help!
> Zoli
>
>
Re: EStore: remove method is invoked right after an adding [message #425543 is a reply to message #425511] Mon, 01 December 2008 12:21 Go to previous messageGo to next message
Zoltan Balogh is currently offline Zoltan BaloghFriend
Messages: 9
Registered: July 2009
Junior Member
Ed,

Comments below.

Ed Merks írta:
> Zoltan,
>
> Comments below.
>
>
> Zoltan Balogh wrote:
>> Hi All,
>>
>> our simple goal is to persist EMF models in a separate store instead
>> of in memory (like in case of CDO), but we don’t need a complex
>> solution like CDO.
> I've seen far more times that I can count when folks assume they can
> build a simpler solution and instead end up with something different
> that's just as complex...

Maybe there will be a complex end of the story... :)

>> In our case there are no dynamic objects (that are not persisted yet)
>> so we assume that every new object is first persisted in the store
> Does "the store" imply an assumption that there is only one store?

There is one store where we have our representation of a given EMF model.

>> and after that we can modify it. With this restriction we made our
>> implementation of InternalEObject extending the EStoreEObjectImpl and
>> write our own ESore implementation. With a minimal modification of the
>> generated editor we could test the implementation.
>>
>> When we try to add a new child to an element, the store’s "add" method
>> is invoked and the adding is happened in our store. But right after
>> that the store’s "remove" method is also invoked with this new element
>> and it’s removed.
> I'd assume some bidirectional handshaking is involved.
>>
>> After debugging the addCommand it seems that during the adding process
>> the old container of the added element is being removed.
> addCommand?

AddCommand that is invoked in case of adding a child to an element in a
generated editor.

>> The problem is that the sore’s "add" method implicitly sets the
>> container of the new element so when the addCommand try to ask for the
>> old container, this will be the new one (because this is also
>> delegating to the store’s getContainer method).
> I'm not sure how the add command is seeing an intermediate state. Al
> the ends of the relationship should be updated at once.
>>
>> I would like to ask that is that any simple solution to bridge this
>> difficulty without working with some kind of dynamic (transient) object?
>>
>> It seems to me that the problem is that the EMF’s adding mechanism is
>> consists of some small atomic steps (e.g. add to list, remove the old
>> container, add new container, etc.) but the store works in little bit
>> higher level (e.g. add method) and there is no way to set the
>> container for example. Or maybe I missed something?
> For both the add and the remove calls to the store, the container is
> provided in the call itself...
>
> It would of course be interesting to look at how CDO deals with this. I
> imagine that if you get a store remove call and the current container
> isn't the first object (container object) given in the remove, that you
> could assume you've been added to a different container already. If
> they match, you could assume the container is becoming null.

In case of eInverseAdd there is a call of eInternalContainer(), that is
returns with an element that is not null so that’s why the old container
is being removed. The problem was not that the addCommand saw an
intermediate state but that a new EStoreEObjectImpl has already his
eContainer to be set to an element.

I studied the CDO implementation a little further and it seems that CDO
overrides the constructor of EStoreEObjectImpl in it’s CDOObjectImpl.
Instead of setting the eContainer to EUNINITIALIZED_CONTAINER
(EUNINITIALIZED_CONTAINER = new EObjectImpl()), CDO’s overridden
constructor set the eContainer to null.

After doing this in our implementation the adding problem is solved so
there was no removing after adding. But we get another problem: Since
eContainer is set to null in the constructor, the eInternalContainer()
returns also null, there is no delegation for EStore’s getContainer().

In CDO the eInternalContainer is also overridden so the correct behavior
is implemented there. But it uses the state information (persistent or
transient) to deduce the correct value. We would like by-pass the
handling of states, so the question is (maybe to Eike :) ) that can we
get correct behavior without working with states?

>>
>> Thanks for Your help!
>> Zoli
>>
>>

Thanks for Your patience!
Re: EStore: remove method is invoked right after an adding [message #425545 is a reply to message #425543] Mon, 01 December 2008 12:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6483
Registered: July 2009
Senior Member
Zoltan,

Comments below...



Zoltan Balogh schrieb:
> Ed,
>
> Comments below.
>
> Ed Merks írta:
>> Zoltan,
>>
>> Comments below.
>>
>>
>> Zoltan Balogh wrote:
>>> Hi All,
>>>
>>> our simple goal is to persist EMF models in a separate store instead
>>> of in memory (like in case of CDO), but we don’t need a complex
>>> solution like CDO.
>> I've seen far more times that I can count when folks assume they can
>> build a simpler solution and instead end up with something different
>> that's just as complex...
>
> Maybe there will be a complex end of the story... :)
>
>>> In our case there are no dynamic objects (that are not persisted
>>> yet) so we assume that every new object is first persisted in the store
>> Does "the store" imply an assumption that there is only one store?
>
> There is one store where we have our representation of a given EMF model.
>
>>> and after that we can modify it. With this restriction we made our
>>> implementation of InternalEObject extending the EStoreEObjectImpl
>>> and write our own ESore implementation. With a minimal modification
>>> of the generated editor we could test the implementation.
>>>
>>> When we try to add a new child to an element, the store’s "add"
>>> method is invoked and the adding is happened in our store. But right
>>> after that the store’s "remove" method is also invoked with this new
>>> element and it’s removed.
>> I'd assume some bidirectional handshaking is involved.
>>>
>>> After debugging the addCommand it seems that during the adding
>>> process the old container of the added element is being removed.
>> addCommand?
>
> AddCommand that is invoked in case of adding a child to an element in
> a generated editor.
>
>>> The problem is that the sore’s "add" method implicitly sets the
>>> container of the new element so when the addCommand try to ask for
>>> the old container, this will be the new one (because this is also
>>> delegating to the store’s getContainer method).
>> I'm not sure how the add command is seeing an intermediate state. Al
>> the ends of the relationship should be updated at once.
>>>
>>> I would like to ask that is that any simple solution to bridge this
>>> difficulty without working with some kind of dynamic (transient)
>>> object?
>>>
>>> It seems to me that the problem is that the EMF’s adding mechanism
>>> is consists of some small atomic steps (e.g. add to list, remove the
>>> old container, add new container, etc.) but the store works in
>>> little bit higher level (e.g. add method) and there is no way to set
>>> the container for example. Or maybe I missed something?
>> For both the add and the remove calls to the store, the container is
>> provided in the call itself...
>>
>> It would of course be interesting to look at how CDO deals with
>> this. I imagine that if you get a store remove call and the current
>> container isn't the first object (container object) given in the
>> remove, that you could assume you've been added to a different
>> container already. If they match, you could assume the container is
>> becoming null.
>
> In case of eInverseAdd there is a call of eInternalContainer(), that
> is returns with an element that is not null so that’s why the old
> container is being removed. The problem was not that the addCommand
> saw an intermediate state but that a new EStoreEObjectImpl has already
> his eContainer to be set to an element.
>
> I studied the CDO implementation a little further and it seems that
> CDO overrides the constructor of EStoreEObjectImpl in it’s
> CDOObjectImpl. Instead of setting the eContainer to
> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
> EObjectImpl()), CDO’s overridden constructor set the eContainer to null.
>
> After doing this in our implementation the adding problem is solved so
> there was no removing after adding. But we get another problem: Since
> eContainer is set to null in the constructor, the eInternalContainer()
> returns also null, there is no delegation for EStore’s getContainer().
>
> In CDO the eInternalContainer is also overridden so the correct
> behavior is implemented there. But it uses the state information
> (persistent or transient) to deduce the correct value. We would like
> by-pass the handling of states, so the question is (maybe to Eike :) )
> that can we get correct behavior without working with states?
I'd say, as long as you don't really have a singleton instance of the
EStore around forany object at any time, then you'll need some
additional object state to bridge then time between object creation and
EStore assignment plus code to properly transition between the states.

Cheers
/Eike

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


Re: EStore: remove method is invoked right after an adding [message #425546 is a reply to message #425545] Mon, 01 December 2008 13:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30898
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010709040506050609030505
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Guys,

Note that CDO has also specialized eBasicSetContainer and that we're
actively discussing how best to push reusable parts of CDO's store
support into the core runtime:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706

One of the discussion points is the extending the store to support
direct delegation for setting the container. That would see the ideal
way to address your issues.

Also related to this stuff is the work for
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501>

https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501

where it would seem to be a good thing if, for the store-based use case,
there's no container field in the object.

I'm cautiously hopeful that we could have some of these things completed
during the quiet weeks late in December...



Eike Stepper wrote:
> Zoltan,
>
> Comments below...
>
>
>
> Zoltan Balogh schrieb:
>> Ed,
>>
>> Comments below.
>>
>> Ed Merks írta:
>>> Zoltan,
>>>
>>> Comments below.
>>>
>>>
>>> Zoltan Balogh wrote:
>>>> Hi All,
>>>>
>>>> our simple goal is to persist EMF models in a separate store
>>>> instead of in memory (like in case of CDO), but we don’t need a
>>>> complex solution like CDO.
>>> I've seen far more times that I can count when folks assume they can
>>> build a simpler solution and instead end up with something different
>>> that's just as complex...
>>
>> Maybe there will be a complex end of the story... :)
>>
>>>> In our case there are no dynamic objects (that are not persisted
>>>> yet) so we assume that every new object is first persisted in the
>>>> store
>>> Does "the store" imply an assumption that there is only one store?
>>
>> There is one store where we have our representation of a given EMF
>> model.
>>
>>>> and after that we can modify it. With this restriction we made our
>>>> implementation of InternalEObject extending the EStoreEObjectImpl
>>>> and write our own ESore implementation. With a minimal modification
>>>> of the generated editor we could test the implementation.
>>>>
>>>> When we try to add a new child to an element, the store’s "add"
>>>> method is invoked and the adding is happened in our store. But
>>>> right after that the store’s "remove" method is also invoked with
>>>> this new element and it’s removed.
>>> I'd assume some bidirectional handshaking is involved.
>>>>
>>>> After debugging the addCommand it seems that during the adding
>>>> process the old container of the added element is being removed.
>>> addCommand?
>>
>> AddCommand that is invoked in case of adding a child to an element in
>> a generated editor.
>>
>>>> The problem is that the sore’s "add" method implicitly sets the
>>>> container of the new element so when the addCommand try to ask for
>>>> the old container, this will be the new one (because this is also
>>>> delegating to the store’s getContainer method).
>>> I'm not sure how the add command is seeing an intermediate state.
>>> Al the ends of the relationship should be updated at once.
>>>>
>>>> I would like to ask that is that any simple solution to bridge this
>>>> difficulty without working with some kind of dynamic (transient)
>>>> object?
>>>>
>>>> It seems to me that the problem is that the EMF’s adding mechanism
>>>> is consists of some small atomic steps (e.g. add to list, remove
>>>> the old container, add new container, etc.) but the store works in
>>>> little bit higher level (e.g. add method) and there is no way to
>>>> set the container for example. Or maybe I missed something?
>>> For both the add and the remove calls to the store, the container is
>>> provided in the call itself...
>>>
>>> It would of course be interesting to look at how CDO deals with
>>> this. I imagine that if you get a store remove call and the current
>>> container isn't the first object (container object) given in the
>>> remove, that you could assume you've been added to a different
>>> container already. If they match, you could assume the container is
>>> becoming null.
>>
>> In case of eInverseAdd there is a call of eInternalContainer(), that
>> is returns with an element that is not null so that’s why the old
>> container is being removed. The problem was not that the addCommand
>> saw an intermediate state but that a new EStoreEObjectImpl has
>> already his eContainer to be set to an element.
>>
>> I studied the CDO implementation a little further and it seems that
>> CDO overrides the constructor of EStoreEObjectImpl in it’s
>> CDOObjectImpl. Instead of setting the eContainer to
>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>> EObjectImpl()), CDO’s overridden constructor set the eContainer to null.
>>
>> After doing this in our implementation the adding problem is solved
>> so there was no removing after adding. But we get another problem:
>> Since eContainer is set to null in the constructor, the
>> eInternalContainer() returns also null, there is no delegation for
>> EStore’s getContainer().
>>
>> In CDO the eInternalContainer is also overridden so the correct
>> behavior is implemented there. But it uses the state information
>> (persistent or transient) to deduce the correct value. We would like
>> by-pass the handling of states, so the question is (maybe to Eike :)
>> ) that can we get correct behavior without working with states?
> I'd say, as long as you don't really have a singleton instance of the
> EStore around forany object at any time, then you'll need some
> additional object state to bridge then time between object creation
> and EStore assignment plus code to properly transition between the
> states.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>

--------------010709040506050609030505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
Note that CDO has also specialized eBasicSetContainer and that we're
actively discussing  how best to push reusable parts of CDO's store
support into the core runtime:<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706">https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706</a><br>
</blockquote>
One of the discussion points is the extending the store to support
direct delegation for setting the container.  That would see the ideal
way to address your issues.<br>
<br>
Also related to this stuff is the work for<a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501"><br>
</a>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501">https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501</a><br>
</blockquote>
where it would seem to be a good thing if, for the store-based use
case, there's no container field in the object.<br>
<br>
I'm cautiously hopeful that we could have some of these things
completed during the quiet weeks late in December...<br>
<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:gh0m34$vfc$6@build.eclipse.org" type="cite">Zoltan,
<br>
<br>
Comments below...
<br>
<br>
<br>
<br>
Zoltan Balogh schrieb:
<br>
<blockquote type="cite">Ed,
<br>
<br>
Comments below.
<br>
<br>
Ed Merks írta:
<br>
<blockquote type="cite">Zoltan,
<br>
<br>
Comments below.
<br>
<br>
<br>
Zoltan Balogh wrote:
<br>
<blockquote type="cite">Hi All,
<br>
<br>
our simple goal is to persist EMF models in a separate store instead of
in memory (like in case of CDO), but we don’t need a complex solution
like CDO.
<br>
</blockquote>
I've seen far more times that I can count when folks assume they can
build a simpler solution and instead end up with something different
that's just as complex...
<br>
</blockquote>
<br>
Maybe there will be a complex end of the story... :)
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">In our case there are no dynamic objects
(that are not persisted yet) so we assume that every new object is
first persisted in the store
<br>
</blockquote>
Does "the store" imply an assumption that there is only one store?
<br>
</blockquote>
<br>
There is one store where we have our representation of a given EMF
model.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">and after that we can modify it. With
this restriction we made our implementation of InternalEObject
extending the EStoreEObjectImpl and write our own ESore implementation.
With a minimal modification of the generated editor we could test the
implementation.
<br>
<br>
When we try to add a new child to an element, the store’s "add" method
is invoked and the adding is happened in our store. But right after
that the store’s "remove" method is also invoked with this new element
and it’s removed.
<br>
</blockquote>
I'd assume some bidirectional handshaking is involved.
<br>
<blockquote type="cite"><br>
After debugging the addCommand it seems that during the adding process
the old container of the added element is being removed. </blockquote>
addCommand?
<br>
</blockquote>
<br>
AddCommand that is invoked in case of adding a child to an element in a
generated editor.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">The problem is that the sore’s "add"
method implicitly sets the container of the new element so when the
addCommand try to ask for the old container, this will be the new one
(because this is also delegating to the store’s getContainer method).
<br>
</blockquote>
I'm not sure how the add command is seeing an intermediate state.  Al
the ends of the relationship should be updated at once.
<br>
<blockquote type="cite"><br>
I would like to ask that is that any simple solution to bridge this
difficulty without working with some kind of dynamic (transient)
object?
<br>
<br>
It seems to me that the problem is that the EMF’s adding mechanism is
consists of some small atomic steps (e.g. add to list, remove the old
container, add new container, etc.) but the store works in little bit
higher level (e.g. add method) and there is no way to set the container
for example. Or maybe I missed something?
<br>
</blockquote>
For both the add and the remove calls to the store, the container is
provided in the call itself...
<br>
<br>
It would of course be interesting to look at how CDO deals with this. 
I imagine that if you get a store remove call and the current container
isn't the first object (container object) given in the remove, that you
could assume you've been added to a different container already.  If
they match, you could assume the container is becoming null.
<br>
</blockquote>
<br>
In case of eInverseAdd there is a call of eInternalContainer(), that is
returns with an element that is not null so that’s why the old
container is being removed. The problem was not that the addCommand saw
an intermediate state but that a new EStoreEObjectImpl has already his
eContainer to be set to an element.
<br>
<br>
I studied the CDO implementation a little further and it seems that CDO
overrides the constructor of EStoreEObjectImpl in it’s CDOObjectImpl.
Instead of setting the eContainer to EUNINITIALIZED_CONTAINER
(EUNINITIALIZED_CONTAINER = new EObjectImpl()), CDO’s overridden
constructor set the eContainer to null.
<br>
<br>
After doing this in our implementation the adding problem is solved so
there was no removing after adding. But we get another problem: Since
eContainer is set to null in the constructor, the eInternalContainer()
returns also null, there is no delegation for EStore’s getContainer().
<br>
<br>
In CDO the eInternalContainer is also overridden so the correct
behavior is implemented there. But it uses the state information
(persistent or transient) to deduce the correct value. We would like
by-pass the handling of states, so the question is (maybe to Eike :) )
that can we get correct behavior without working with states?
<br>
</blockquote>
I'd say, as long as you don't really have a singleton instance of the
EStore around forany object at any time, then you'll need some
additional object state to bridge then time between object creation and
EStore assignment plus code to properly transition between the states.
<br>
<br>
Cheers
<br>
/Eike
<br>
<br>
----
<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<br>
<br>
</blockquote>
</body>
</html>

--------------010709040506050609030505--
Re: EStore: remove method is invoked right after an adding [message #425550 is a reply to message #425546] Mon, 01 December 2008 14:16 Go to previous messageGo to next message
Zoltan Balogh is currently offline Zoltan BaloghFriend
Messages: 9
Registered: July 2009
Junior Member
Ed,
comments below

Ed Merks írta:
> Guys,
>
> Note that CDO has also specialized eBasicSetContainer and that we're
> actively discussing how best to push reusable parts of CDO's store
> support into the core runtime:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706
>
> One of the discussion points is the extending the store to support
> direct delegation for setting the container. That would see the ideal
> way to address your issues.

Definitely it would be a great solution to my problem.
Without having the setter of the container in EStore, it’s a little bit
difficult to extend EMF with our own storing mechanism.

>
> Also related to this stuff is the work for
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501
>
> where it would seem to be a good thing if, for the store-based use case,
> there's no container field in the object.
>
> I'm cautiously hopeful that we could have some of these things completed
> during the quiet weeks late in December...

ok, then we’re waiting!
Thanks, this letter has already helped a lot!

>
>
>
> Eike Stepper wrote:
>> Zoltan,
>>
>> Comments below...
>>
>>
>>
>> Zoltan Balogh schrieb:
>>> Ed,
>>>
>>> Comments below.
>>>
>>> Ed Merks írta:
>>>> Zoltan,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Zoltan Balogh wrote:
>>>>> Hi All,
>>>>>
>>>>> our simple goal is to persist EMF models in a separate store
>>>>> instead of in memory (like in case of CDO), but we don’t need a
>>>>> complex solution like CDO.
>>>> I've seen far more times that I can count when folks assume they can
>>>> build a simpler solution and instead end up with something different
>>>> that's just as complex...
>>>
>>> Maybe there will be a complex end of the story... :)
>>>
>>>>> In our case there are no dynamic objects (that are not persisted
>>>>> yet) so we assume that every new object is first persisted in the
>>>>> store
>>>> Does "the store" imply an assumption that there is only one store?
>>>
>>> There is one store where we have our representation of a given EMF
>>> model.
>>>
>>>>> and after that we can modify it. With this restriction we made our
>>>>> implementation of InternalEObject extending the EStoreEObjectImpl
>>>>> and write our own ESore implementation. With a minimal modification
>>>>> of the generated editor we could test the implementation.
>>>>>
>>>>> When we try to add a new child to an element, the store’s "add"
>>>>> method is invoked and the adding is happened in our store. But
>>>>> right after that the store’s "remove" method is also invoked with
>>>>> this new element and it’s removed.
>>>> I'd assume some bidirectional handshaking is involved.
>>>>>
>>>>> After debugging the addCommand it seems that during the adding
>>>>> process the old container of the added element is being removed.
>>>> addCommand?
>>>
>>> AddCommand that is invoked in case of adding a child to an element in
>>> a generated editor.
>>>
>>>>> The problem is that the sore’s "add" method implicitly sets the
>>>>> container of the new element so when the addCommand try to ask for
>>>>> the old container, this will be the new one (because this is also
>>>>> delegating to the store’s getContainer method).
>>>> I'm not sure how the add command is seeing an intermediate state.
>>>> Al the ends of the relationship should be updated at once.
>>>>>
>>>>> I would like to ask that is that any simple solution to bridge this
>>>>> difficulty without working with some kind of dynamic (transient)
>>>>> object?
>>>>>
>>>>> It seems to me that the problem is that the EMF’s adding mechanism
>>>>> is consists of some small atomic steps (e.g. add to list, remove
>>>>> the old container, add new container, etc.) but the store works in
>>>>> little bit higher level (e.g. add method) and there is no way to
>>>>> set the container for example. Or maybe I missed something?
>>>> For both the add and the remove calls to the store, the container is
>>>> provided in the call itself...
>>>>
>>>> It would of course be interesting to look at how CDO deals with
>>>> this. I imagine that if you get a store remove call and the current
>>>> container isn't the first object (container object) given in the
>>>> remove, that you could assume you've been added to a different
>>>> container already. If they match, you could assume the container is
>>>> becoming null.
>>>
>>> In case of eInverseAdd there is a call of eInternalContainer(), that
>>> is returns with an element that is not null so that’s why the old
>>> container is being removed. The problem was not that the addCommand
>>> saw an intermediate state but that a new EStoreEObjectImpl has
>>> already his eContainer to be set to an element.
>>>
>>> I studied the CDO implementation a little further and it seems that
>>> CDO overrides the constructor of EStoreEObjectImpl in it’s
>>> CDOObjectImpl. Instead of setting the eContainer to
>>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>>> EObjectImpl()), CDO’s overridden constructor set the eContainer to null.
>>>
>>> After doing this in our implementation the adding problem is solved
>>> so there was no removing after adding. But we get another problem:
>>> Since eContainer is set to null in the constructor, the
>>> eInternalContainer() returns also null, there is no delegation for
>>> EStore’s getContainer().
>>>
>>> In CDO the eInternalContainer is also overridden so the correct
>>> behavior is implemented there. But it uses the state information
>>> (persistent or transient) to deduce the correct value. We would like
>>> by-pass the handling of states, so the question is (maybe to Eike :)
>>> ) that can we get correct behavior without working with states?
>> I'd say, as long as you don't really have a singleton instance of the
>> EStore around forany object at any time, then you'll need some
>> additional object state to bridge then time between object creation
>> and EStore assignment plus code to properly transition between the
>> states.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
Re: EStore: remove method is invoked right after an adding [message #425551 is a reply to message #425545] Mon, 01 December 2008 14:19 Go to previous messageGo to next message
Zoltan Balogh is currently offline Zoltan BaloghFriend
Messages: 9
Registered: July 2009
Junior Member
Eike,

we would like to make a "real live" implementation of the storing
mechanism, which means that the EMF objects never has a state stored in
memory, their states are immediately persisted in our store. Therefore
it’s hard to find when we have to do the transition between the states
and whose responsibility should it be. In CDO there is a definite point
for that: the moment of saving, if I’m not mistaken. We don't have such
a point.

Thanks, that you pointed to the fact that with the current state of
Estore we can’t do our work as easily as we thought!

By the way according to Ed’s letter, maybe we have to wait for the EMF
store’s enhancement that will solve our problem.



Eike Stepper írta:
> Zoltan,
>
> Comments below...
>
>
>
> Zoltan Balogh schrieb:
>> Ed,
>>
>> Comments below.
>>
>> Ed Merks írta:
>>> Zoltan,
>>>
>>> Comments below.
>>>
>>>
>>> Zoltan Balogh wrote:
>>>> Hi All,
>>>>
>>>> our simple goal is to persist EMF models in a separate store instead
>>>> of in memory (like in case of CDO), but we don’t need a complex
>>>> solution like CDO.
>>> I've seen far more times that I can count when folks assume they can
>>> build a simpler solution and instead end up with something different
>>> that's just as complex...
>>
>> Maybe there will be a complex end of the story... :)
>>
>>>> In our case there are no dynamic objects (that are not persisted
>>>> yet) so we assume that every new object is first persisted in the store
>>> Does "the store" imply an assumption that there is only one store?
>>
>> There is one store where we have our representation of a given EMF model.
>>
>>>> and after that we can modify it. With this restriction we made our
>>>> implementation of InternalEObject extending the EStoreEObjectImpl
>>>> and write our own ESore implementation. With a minimal modification
>>>> of the generated editor we could test the implementation.
>>>>
>>>> When we try to add a new child to an element, the store’s "add"
>>>> method is invoked and the adding is happened in our store. But right
>>>> after that the store’s "remove" method is also invoked with this new
>>>> element and it’s removed.
>>> I'd assume some bidirectional handshaking is involved.
>>>>
>>>> After debugging the addCommand it seems that during the adding
>>>> process the old container of the added element is being removed.
>>> addCommand?
>>
>> AddCommand that is invoked in case of adding a child to an element in
>> a generated editor.
>>
>>>> The problem is that the sore’s "add" method implicitly sets the
>>>> container of the new element so when the addCommand try to ask for
>>>> the old container, this will be the new one (because this is also
>>>> delegating to the store’s getContainer method).
>>> I'm not sure how the add command is seeing an intermediate state. Al
>>> the ends of the relationship should be updated at once.
>>>>
>>>> I would like to ask that is that any simple solution to bridge this
>>>> difficulty without working with some kind of dynamic (transient)
>>>> object?
>>>>
>>>> It seems to me that the problem is that the EMF’s adding mechanism
>>>> is consists of some small atomic steps (e.g. add to list, remove the
>>>> old container, add new container, etc.) but the store works in
>>>> little bit higher level (e.g. add method) and there is no way to set
>>>> the container for example. Or maybe I missed something?
>>> For both the add and the remove calls to the store, the container is
>>> provided in the call itself...
>>>
>>> It would of course be interesting to look at how CDO deals with
>>> this. I imagine that if you get a store remove call and the current
>>> container isn't the first object (container object) given in the
>>> remove, that you could assume you've been added to a different
>>> container already. If they match, you could assume the container is
>>> becoming null.
>>
>> In case of eInverseAdd there is a call of eInternalContainer(), that
>> is returns with an element that is not null so that’s why the old
>> container is being removed. The problem was not that the addCommand
>> saw an intermediate state but that a new EStoreEObjectImpl has already
>> his eContainer to be set to an element.
>>
>> I studied the CDO implementation a little further and it seems that
>> CDO overrides the constructor of EStoreEObjectImpl in it’s
>> CDOObjectImpl. Instead of setting the eContainer to
>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>> EObjectImpl()), CDO’s overridden constructor set the eContainer to null.
>>
>> After doing this in our implementation the adding problem is solved so
>> there was no removing after adding. But we get another problem: Since
>> eContainer is set to null in the constructor, the eInternalContainer()
>> returns also null, there is no delegation for EStore’s getContainer().
>>
>> In CDO the eInternalContainer is also overridden so the correct
>> behavior is implemented there. But it uses the state information
>> (persistent or transient) to deduce the correct value. We would like
>> by-pass the handling of states, so the question is (maybe to Eike :) )
>> that can we get correct behavior without working with states?
> I'd say, as long as you don't really have a singleton instance of the
> EStore around forany object at any time, then you'll need some
> additional object state to bridge then time between object creation and
> EStore assignment plus code to properly transition between the states.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
Re: EStore: remove method is invoked right after an adding [message #425559 is a reply to message #425551] Mon, 01 December 2008 16:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30898
Registered: July 2009
Senior Member
Zoltan,

If I understand some of CDO's design correctly, attaching the object to
a store-based resource would be such a transition point. This way the
resource determines which store should be used.


Zoltan Balogh wrote:
> Eike,
>
> we would like to make a "real live" implementation of the storing
> mechanism, which means that the EMF objects never has a state stored
> in memory, their states are immediately persisted in our store.
> Therefore it’s hard to find when we have to do the transition between
> the states and whose responsibility should it be. In CDO there is a
> definite point for that: the moment of saving, if I’m not mistaken. We
> don't have such a point.
>
> Thanks, that you pointed to the fact that with the current state of
> Estore we can’t do our work as easily as we thought!
>
> By the way according to Ed’s letter, maybe we have to wait for the EMF
> store’s enhancement that will solve our problem.
>
>
>
> Eike Stepper írta:
>> Zoltan,
>>
>> Comments below...
>>
>>
>>
>> Zoltan Balogh schrieb:
>>> Ed,
>>>
>>> Comments below.
>>>
>>> Ed Merks írta:
>>>> Zoltan,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Zoltan Balogh wrote:
>>>>> Hi All,
>>>>>
>>>>> our simple goal is to persist EMF models in a separate store
>>>>> instead of in memory (like in case of CDO), but we don’t need a
>>>>> complex solution like CDO.
>>>> I've seen far more times that I can count when folks assume they
>>>> can build a simpler solution and instead end up with something
>>>> different that's just as complex...
>>>
>>> Maybe there will be a complex end of the story... :)
>>>
>>>>> In our case there are no dynamic objects (that are not persisted
>>>>> yet) so we assume that every new object is first persisted in the
>>>>> store
>>>> Does "the store" imply an assumption that there is only one store?
>>>
>>> There is one store where we have our representation of a given EMF
>>> model.
>>>
>>>>> and after that we can modify it. With this restriction we made our
>>>>> implementation of InternalEObject extending the EStoreEObjectImpl
>>>>> and write our own ESore implementation. With a minimal
>>>>> modification of the generated editor we could test the
>>>>> implementation.
>>>>>
>>>>> When we try to add a new child to an element, the store’s "add"
>>>>> method is invoked and the adding is happened in our store. But
>>>>> right after that the store’s "remove" method is also invoked with
>>>>> this new element and it’s removed.
>>>> I'd assume some bidirectional handshaking is involved.
>>>>>
>>>>> After debugging the addCommand it seems that during the adding
>>>>> process the old container of the added element is being removed.
>>>> addCommand?
>>>
>>> AddCommand that is invoked in case of adding a child to an element
>>> in a generated editor.
>>>
>>>>> The problem is that the sore’s "add" method implicitly sets the
>>>>> container of the new element so when the addCommand try to ask for
>>>>> the old container, this will be the new one (because this is also
>>>>> delegating to the store’s getContainer method).
>>>> I'm not sure how the add command is seeing an intermediate state.
>>>> Al the ends of the relationship should be updated at once.
>>>>>
>>>>> I would like to ask that is that any simple solution to bridge
>>>>> this difficulty without working with some kind of dynamic
>>>>> (transient) object?
>>>>>
>>>>> It seems to me that the problem is that the EMF’s adding mechanism
>>>>> is consists of some small atomic steps (e.g. add to list, remove
>>>>> the old container, add new container, etc.) but the store works in
>>>>> little bit higher level (e.g. add method) and there is no way to
>>>>> set the container for example. Or maybe I missed something?
>>>> For both the add and the remove calls to the store, the container
>>>> is provided in the call itself...
>>>>
>>>> It would of course be interesting to look at how CDO deals with
>>>> this. I imagine that if you get a store remove call and the
>>>> current container isn't the first object (container object) given
>>>> in the remove, that you could assume you've been added to a
>>>> different container already. If they match, you could assume the
>>>> container is becoming null.
>>>
>>> In case of eInverseAdd there is a call of eInternalContainer(), that
>>> is returns with an element that is not null so that’s why the old
>>> container is being removed. The problem was not that the addCommand
>>> saw an intermediate state but that a new EStoreEObjectImpl has
>>> already his eContainer to be set to an element.
>>>
>>> I studied the CDO implementation a little further and it seems that
>>> CDO overrides the constructor of EStoreEObjectImpl in it’s
>>> CDOObjectImpl. Instead of setting the eContainer to
>>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>>> EObjectImpl()), CDO’s overridden constructor set the eContainer to
>>> null.
>>>
>>> After doing this in our implementation the adding problem is solved
>>> so there was no removing after adding. But we get another problem:
>>> Since eContainer is set to null in the constructor, the
>>> eInternalContainer() returns also null, there is no delegation for
>>> EStore’s getContainer().
>>>
>>> In CDO the eInternalContainer is also overridden so the correct
>>> behavior is implemented there. But it uses the state information
>>> (persistent or transient) to deduce the correct value. We would like
>>> by-pass the handling of states, so the question is (maybe to Eike :)
>>> ) that can we get correct behavior without working with states?
>> I'd say, as long as you don't really have a singleton instance of the
>> EStore around forany object at any time, then you'll need some
>> additional object state to bridge then time between object creation
>> and EStore assignment plus code to properly transition between the
>> states.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
Re: EStore: remove method is invoked right after an adding [message #425561 is a reply to message #425559] Mon, 01 December 2008 16:19 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6483
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Zoltan,
>
> If I understand some of CDO's design correctly, attaching the object
> to a store-based resource would be such a transition point.
Exactly. I think COMMIT ( aka save) would also be an appropirate event
to trigger data migration but we chose the earliest possible event.

> This way the resource determines which store should be used.
Yes.

Cheers
/Eike

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


>
>
> Zoltan Balogh wrote:
>> Eike,
>>
>> we would like to make a "real live" implementation of the storing
>> mechanism, which means that the EMF objects never has a state stored
>> in memory, their states are immediately persisted in our store.
>> Therefore it’s hard to find when we have to do the transition between
>> the states and whose responsibility should it be. In CDO there is a
>> definite point for that: the moment of saving, if I’m not mistaken.
>> We don't have such a point.
>>
>> Thanks, that you pointed to the fact that with the current state of
>> Estore we can’t do our work as easily as we thought!
>>
>> By the way according to Ed’s letter, maybe we have to wait for the
>> EMF store’s enhancement that will solve our problem.
>>
>>
>>
>> Eike Stepper írta:
>>> Zoltan,
>>>
>>> Comments below...
>>>
>>>
>>>
>>> Zoltan Balogh schrieb:
>>>> Ed,
>>>>
>>>> Comments below.
>>>>
>>>> Ed Merks írta:
>>>>> Zoltan,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Zoltan Balogh wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> our simple goal is to persist EMF models in a separate store
>>>>>> instead of in memory (like in case of CDO), but we don’t need a
>>>>>> complex solution like CDO.
>>>>> I've seen far more times that I can count when folks assume they
>>>>> can build a simpler solution and instead end up with something
>>>>> different that's just as complex...
>>>>
>>>> Maybe there will be a complex end of the story... :)
>>>>
>>>>>> In our case there are no dynamic objects (that are not persisted
>>>>>> yet) so we assume that every new object is first persisted in the
>>>>>> store
>>>>> Does "the store" imply an assumption that there is only one store?
>>>>
>>>> There is one store where we have our representation of a given EMF
>>>> model.
>>>>
>>>>>> and after that we can modify it. With this restriction we made
>>>>>> our implementation of InternalEObject extending the
>>>>>> EStoreEObjectImpl and write our own ESore implementation. With a
>>>>>> minimal modification of the generated editor we could test the
>>>>>> implementation.
>>>>>>
>>>>>> When we try to add a new child to an element, the store’s "add"
>>>>>> method is invoked and the adding is happened in our store. But
>>>>>> right after that the store’s "remove" method is also invoked with
>>>>>> this new element and it’s removed.
>>>>> I'd assume some bidirectional handshaking is involved.
>>>>>>
>>>>>> After debugging the addCommand it seems that during the adding
>>>>>> process the old container of the added element is being removed.
>>>>> addCommand?
>>>>
>>>> AddCommand that is invoked in case of adding a child to an element
>>>> in a generated editor.
>>>>
>>>>>> The problem is that the sore’s "add" method implicitly sets the
>>>>>> container of the new element so when the addCommand try to ask
>>>>>> for the old container, this will be the new one (because this is
>>>>>> also delegating to the store’s getContainer method).
>>>>> I'm not sure how the add command is seeing an intermediate state.
>>>>> Al the ends of the relationship should be updated at once.
>>>>>>
>>>>>> I would like to ask that is that any simple solution to bridge
>>>>>> this difficulty without working with some kind of dynamic
>>>>>> (transient) object?
>>>>>>
>>>>>> It seems to me that the problem is that the EMF’s adding
>>>>>> mechanism is consists of some small atomic steps (e.g. add to
>>>>>> list, remove the old container, add new container, etc.) but the
>>>>>> store works in little bit higher level (e.g. add method) and
>>>>>> there is no way to set the container for example. Or maybe I
>>>>>> missed something?
>>>>> For both the add and the remove calls to the store, the container
>>>>> is provided in the call itself...
>>>>>
>>>>> It would of course be interesting to look at how CDO deals with
>>>>> this. I imagine that if you get a store remove call and the
>>>>> current container isn't the first object (container object) given
>>>>> in the remove, that you could assume you've been added to a
>>>>> different container already. If they match, you could assume the
>>>>> container is becoming null.
>>>>
>>>> In case of eInverseAdd there is a call of eInternalContainer(),
>>>> that is returns with an element that is not null so that’s why the
>>>> old container is being removed. The problem was not that the
>>>> addCommand saw an intermediate state but that a new
>>>> EStoreEObjectImpl has already his eContainer to be set to an element.
>>>>
>>>> I studied the CDO implementation a little further and it seems that
>>>> CDO overrides the constructor of EStoreEObjectImpl in it’s
>>>> CDOObjectImpl. Instead of setting the eContainer to
>>>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>>>> EObjectImpl()), CDO’s overridden constructor set the eContainer to
>>>> null.
>>>>
>>>> After doing this in our implementation the adding problem is solved
>>>> so there was no removing after adding. But we get another problem:
>>>> Since eContainer is set to null in the constructor, the
>>>> eInternalContainer() returns also null, there is no delegation for
>>>> EStore’s getContainer().
>>>>
>>>> In CDO the eInternalContainer is also overridden so the correct
>>>> behavior is implemented there. But it uses the state information
>>>> (persistent or transient) to deduce the correct value. We would
>>>> like by-pass the handling of states, so the question is (maybe to
>>>> Eike :) ) that can we get correct behavior without working with
>>>> states?
>>> I'd say, as long as you don't really have a singleton instance of
>>> the EStore around forany object at any time, then you'll need some
>>> additional object state to bridge then time between object creation
>>> and EStore assignment plus code to properly transition between the
>>> states.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>


Re: EStore: remove method is invoked right after an adding [message #425564 is a reply to message #425561] Mon, 01 December 2008 16:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30898
Registered: July 2009
Senior Member
Eike,

Yes, this issue of when first a connection with the server is
established, i.e., during input or output stream creation or earlier is
something we're still discussing. :-)


Eike Stepper wrote:
> Ed Merks schrieb:
>> Zoltan,
>>
>> If I understand some of CDO's design correctly, attaching the object
>> to a store-based resource would be such a transition point.
> Exactly. I think COMMIT ( aka save) would also be an appropirate event
> to trigger data migration but we chose the earliest possible event.
>
>> This way the resource determines which store should be used.
> Yes.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>>
>>
>> Zoltan Balogh wrote:
>>> Eike,
>>>
>>> we would like to make a "real live" implementation of the storing
>>> mechanism, which means that the EMF objects never has a state stored
>>> in memory, their states are immediately persisted in our store.
>>> Therefore it’s hard to find when we have to do the transition
>>> between the states and whose responsibility should it be. In CDO
>>> there is a definite point for that: the moment of saving, if I’m not
>>> mistaken. We don't have such a point.
>>>
>>> Thanks, that you pointed to the fact that with the current state of
>>> Estore we can’t do our work as easily as we thought!
>>>
>>> By the way according to Ed’s letter, maybe we have to wait for the
>>> EMF store’s enhancement that will solve our problem.
>>>
>>>
>>>
>>> Eike Stepper írta:
>>>> Zoltan,
>>>>
>>>> Comments below...
>>>>
>>>>
>>>>
>>>> Zoltan Balogh schrieb:
>>>>> Ed,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Ed Merks írta:
>>>>>> Zoltan,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> Zoltan Balogh wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> our simple goal is to persist EMF models in a separate store
>>>>>>> instead of in memory (like in case of CDO), but we don’t need a
>>>>>>> complex solution like CDO.
>>>>>> I've seen far more times that I can count when folks assume they
>>>>>> can build a simpler solution and instead end up with something
>>>>>> different that's just as complex...
>>>>>
>>>>> Maybe there will be a complex end of the story... :)
>>>>>
>>>>>>> In our case there are no dynamic objects (that are not persisted
>>>>>>> yet) so we assume that every new object is first persisted in
>>>>>>> the store
>>>>>> Does "the store" imply an assumption that there is only one store?
>>>>>
>>>>> There is one store where we have our representation of a given EMF
>>>>> model.
>>>>>
>>>>>>> and after that we can modify it. With this restriction we made
>>>>>>> our implementation of InternalEObject extending the
>>>>>>> EStoreEObjectImpl and write our own ESore implementation. With a
>>>>>>> minimal modification of the generated editor we could test the
>>>>>>> implementation.
>>>>>>>
>>>>>>> When we try to add a new child to an element, the store’s "add"
>>>>>>> method is invoked and the adding is happened in our store. But
>>>>>>> right after that the store’s "remove" method is also invoked
>>>>>>> with this new element and it’s removed.
>>>>>> I'd assume some bidirectional handshaking is involved.
>>>>>>>
>>>>>>> After debugging the addCommand it seems that during the adding
>>>>>>> process the old container of the added element is being removed.
>>>>>> addCommand?
>>>>>
>>>>> AddCommand that is invoked in case of adding a child to an element
>>>>> in a generated editor.
>>>>>
>>>>>>> The problem is that the sore’s "add" method implicitly sets the
>>>>>>> container of the new element so when the addCommand try to ask
>>>>>>> for the old container, this will be the new one (because this is
>>>>>>> also delegating to the store’s getContainer method).
>>>>>> I'm not sure how the add command is seeing an intermediate
>>>>>> state. Al the ends of the relationship should be updated at once.
>>>>>>>
>>>>>>> I would like to ask that is that any simple solution to bridge
>>>>>>> this difficulty without working with some kind of dynamic
>>>>>>> (transient) object?
>>>>>>>
>>>>>>> It seems to me that the problem is that the EMF’s adding
>>>>>>> mechanism is consists of some small atomic steps (e.g. add to
>>>>>>> list, remove the old container, add new container, etc.) but the
>>>>>>> store works in little bit higher level (e.g. add method) and
>>>>>>> there is no way to set the container for example. Or maybe I
>>>>>>> missed something?
>>>>>> For both the add and the remove calls to the store, the container
>>>>>> is provided in the call itself...
>>>>>>
>>>>>> It would of course be interesting to look at how CDO deals with
>>>>>> this. I imagine that if you get a store remove call and the
>>>>>> current container isn't the first object (container object) given
>>>>>> in the remove, that you could assume you've been added to a
>>>>>> different container already. If they match, you could assume the
>>>>>> container is becoming null.
>>>>>
>>>>> In case of eInverseAdd there is a call of eInternalContainer(),
>>>>> that is returns with an element that is not null so that’s why the
>>>>> old container is being removed. The problem was not that the
>>>>> addCommand saw an intermediate state but that a new
>>>>> EStoreEObjectImpl has already his eContainer to be set to an element.
>>>>>
>>>>> I studied the CDO implementation a little further and it seems
>>>>> that CDO overrides the constructor of EStoreEObjectImpl in it’s
>>>>> CDOObjectImpl. Instead of setting the eContainer to
>>>>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>>>>> EObjectImpl()), CDO’s overridden constructor set the eContainer to
>>>>> null.
>>>>>
>>>>> After doing this in our implementation the adding problem is
>>>>> solved so there was no removing after adding. But we get another
>>>>> problem: Since eContainer is set to null in the constructor, the
>>>>> eInternalContainer() returns also null, there is no delegation for
>>>>> EStore’s getContainer().
>>>>>
>>>>> In CDO the eInternalContainer is also overridden so the correct
>>>>> behavior is implemented there. But it uses the state information
>>>>> (persistent or transient) to deduce the correct value. We would
>>>>> like by-pass the handling of states, so the question is (maybe to
>>>>> Eike :) ) that can we get correct behavior without working with
>>>>> states?
>>>> I'd say, as long as you don't really have a singleton instance of
>>>> the EStore around forany object at any time, then you'll need some
>>>> additional object state to bridge then time between object creation
>>>> and EStore assignment plus code to properly transition between the
>>>> states.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
Re: EStore: remove method is invoked right after an adding [message #425581 is a reply to message #425559] Tue, 02 December 2008 15:04 Go to previous message
Zoltan Balogh is currently offline Zoltan BaloghFriend
Messages: 9
Registered: July 2009
Junior Member
Ed,

yes, the solution for the whole problem was the usage of attaching the
objects. It was unfortunately overlooked by us...

Anyway we had to use two primitive states for the objects to achieve the
proper behavior and had to override the eInternalContainer() and
eContainerFeatureID(). As I understand this kind of workaround will be
eliminated in the further extension of the store as you mentioned
earlier. ;)

Ed Merks írta:
> Zoltan,
>
> If I understand some of CDO's design correctly, attaching the object to
> a store-based resource would be such a transition point. This way the
> resource determines which store should be used.
>
>
> Zoltan Balogh wrote:
>> Eike,
>>
>> we would like to make a "real live" implementation of the storing
>> mechanism, which means that the EMF objects never has a state stored
>> in memory, their states are immediately persisted in our store.
>> Therefore it’s hard to find when we have to do the transition between
>> the states and whose responsibility should it be. In CDO there is a
>> definite point for that: the moment of saving, if I’m not mistaken. We
>> don't have such a point.
>>
>> Thanks, that you pointed to the fact that with the current state of
>> Estore we can’t do our work as easily as we thought!
>>
>> By the way according to Ed’s letter, maybe we have to wait for the EMF
>> store’s enhancement that will solve our problem.
>>
>>
>>
>> Eike Stepper írta:
>>> Zoltan,
>>>
>>> Comments below...
>>>
>>>
>>>
>>> Zoltan Balogh schrieb:
>>>> Ed,
>>>>
>>>> Comments below.
>>>>
>>>> Ed Merks írta:
>>>>> Zoltan,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Zoltan Balogh wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> our simple goal is to persist EMF models in a separate store
>>>>>> instead of in memory (like in case of CDO), but we don’t need a
>>>>>> complex solution like CDO.
>>>>> I've seen far more times that I can count when folks assume they
>>>>> can build a simpler solution and instead end up with something
>>>>> different that's just as complex...
>>>>
>>>> Maybe there will be a complex end of the story... :)
>>>>
>>>>>> In our case there are no dynamic objects (that are not persisted
>>>>>> yet) so we assume that every new object is first persisted in the
>>>>>> store
>>>>> Does "the store" imply an assumption that there is only one store?
>>>>
>>>> There is one store where we have our representation of a given EMF
>>>> model.
>>>>
>>>>>> and after that we can modify it. With this restriction we made our
>>>>>> implementation of InternalEObject extending the EStoreEObjectImpl
>>>>>> and write our own ESore implementation. With a minimal
>>>>>> modification of the generated editor we could test the
>>>>>> implementation.
>>>>>>
>>>>>> When we try to add a new child to an element, the store’s "add"
>>>>>> method is invoked and the adding is happened in our store. But
>>>>>> right after that the store’s "remove" method is also invoked with
>>>>>> this new element and it’s removed.
>>>>> I'd assume some bidirectional handshaking is involved.
>>>>>>
>>>>>> After debugging the addCommand it seems that during the adding
>>>>>> process the old container of the added element is being removed.
>>>>> addCommand?
>>>>
>>>> AddCommand that is invoked in case of adding a child to an element
>>>> in a generated editor.
>>>>
>>>>>> The problem is that the sore’s "add" method implicitly sets the
>>>>>> container of the new element so when the addCommand try to ask for
>>>>>> the old container, this will be the new one (because this is also
>>>>>> delegating to the store’s getContainer method).
>>>>> I'm not sure how the add command is seeing an intermediate state.
>>>>> Al the ends of the relationship should be updated at once.
>>>>>>
>>>>>> I would like to ask that is that any simple solution to bridge
>>>>>> this difficulty without working with some kind of dynamic
>>>>>> (transient) object?
>>>>>>
>>>>>> It seems to me that the problem is that the EMF’s adding mechanism
>>>>>> is consists of some small atomic steps (e.g. add to list, remove
>>>>>> the old container, add new container, etc.) but the store works in
>>>>>> little bit higher level (e.g. add method) and there is no way to
>>>>>> set the container for example. Or maybe I missed something?
>>>>> For both the add and the remove calls to the store, the container
>>>>> is provided in the call itself...
>>>>>
>>>>> It would of course be interesting to look at how CDO deals with
>>>>> this. I imagine that if you get a store remove call and the
>>>>> current container isn't the first object (container object) given
>>>>> in the remove, that you could assume you've been added to a
>>>>> different container already. If they match, you could assume the
>>>>> container is becoming null.
>>>>
>>>> In case of eInverseAdd there is a call of eInternalContainer(), that
>>>> is returns with an element that is not null so that’s why the old
>>>> container is being removed. The problem was not that the addCommand
>>>> saw an intermediate state but that a new EStoreEObjectImpl has
>>>> already his eContainer to be set to an element.
>>>>
>>>> I studied the CDO implementation a little further and it seems that
>>>> CDO overrides the constructor of EStoreEObjectImpl in it’s
>>>> CDOObjectImpl. Instead of setting the eContainer to
>>>> EUNINITIALIZED_CONTAINER (EUNINITIALIZED_CONTAINER = new
>>>> EObjectImpl()), CDO’s overridden constructor set the eContainer to
>>>> null.
>>>>
>>>> After doing this in our implementation the adding problem is solved
>>>> so there was no removing after adding. But we get another problem:
>>>> Since eContainer is set to null in the constructor, the
>>>> eInternalContainer() returns also null, there is no delegation for
>>>> EStore’s getContainer().
>>>>
>>>> In CDO the eInternalContainer is also overridden so the correct
>>>> behavior is implemented there. But it uses the state information
>>>> (persistent or transient) to deduce the correct value. We would like
>>>> by-pass the handling of states, so the question is (maybe to Eike :)
>>>> ) that can we get correct behavior without working with states?
>>> I'd say, as long as you don't really have a singleton instance of the
>>> EStore around forany object at any time, then you'll need some
>>> additional object state to bridge then time between object creation
>>> and EStore assignment plus code to properly transition between the
>>> states.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
Previous Topic:Re: CDO 1.0.4 problem: Revision not found
Next Topic:[CDO] User ID on revision
Goto Forum:
  


Current Time: Mon Feb 24 12:37:54 GMT 2020

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

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

Back to the top