Editing contexts within the same EOF stack get notified of changes and
merge those in.
This is unfortunately not always desirable behavior. A user could
successfully overwrite information that is more recent than what he
has seen displayed. I.e. if changes happened within the same EOF
stack, they would have gotten merged into the local editing context.
This contrasts with the behavior exhibited when changes were made in a
separate EOF stack (e.g. another app instance). In that event the save
operation would fail with an optimistic locking exception. The app can
then report to the users the fact that some other user managed to
squeeze in a change.
If you prefer changes to always be merged in, you may implement change
notifications between stacks and app instances.
If you want your user always to see the data he is about to overwrite,
you may simulate the optimistic locking behavior by listening to the
notifications which trigger merging.
Pierre
On Sep 6, 2009, at 11:22 AM, Johann Werner wrote:
Am 06.09.2009 um 10:29 schrieb Chan Yeow Heong, Jerome:
So what happens after I do
nested.save();
This commits all changes of nested to original.
original.save();
This commits all changes of original to the data storage (mostly
this will be the database).
Does nested go away? Does it get garbage collected?
If you don't hold any references to nested anymore then yes it will
be garbage collected.
What is the editing context of the objects manipulated after both
saves are done? Is it original?
You mean if there were additional changes in original (made outside
of nested) are they reflected in nested? Looking at http://developer.apple.com/legacy/mac/library/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/Topics/ProgrammingTopics.39.html
a nested editing context behaves as any other 'normal' one. A
standard editing context doesn't see changes in the database unless
it refetches its objects. So I would guess that the nested editing
context doesn't see the changes that were made outside of it in the
parent unless you 'refetch' them into it. But this is just a guess,
I use nested editing contexts very rarely in special cases. A safe
method would be to throw your old nested editing context away and
create a new one after the save. As it doesn't have to make a
roundtrip to the database which would cost time, it gets its objects
from another editing context in memory which won't cause a
noticeable delay.
On 05-Sep-2009, at 6:47 PM, Johann Werner wrote:
Hi Jerome,
Am 05.09.2009 um 11:50 schrieb Chan Yeow Heong, Jerome:
When I'm using nested editing contexts, do I need to call revert
on a original editing context when I call revert on the nested
context?
EOEditingContext original = ERXEC.newEditingContext(true);
EOEditingContext nested = ERXEC.newEditingContext(original,true);
... do some work ...
... something went wrong and we have to cancel all changes ...
nested.revert();
original.revert(); // <-- Is this second call needed?
No, this call is not needed. A nested editing context behaves as
any other 'normal' editing context with the only difference that
saving the context doesn't push your changes to the db but into
the parent context. So either call revert on your nested context
or just discard the context and replace it by a new one.
jw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jw%40oyosys.de
This email sent to j...@oyosys.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/pierre.bernard%40lists.houdah.com
This email sent to pierre.bern...@lists.houdah.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
