Pierre,
I think this is one of the clearest explanations of the
EOEditingContext I've seen. That used to trip me up a lot when first
learning WO. I used the session's defaulting editing context for all
kinds of stuff. I just thought that was the right way by reading the
documentation on EOF. It wasn't until later that I discovered all the
problems that created.
I agree use the default editing context sparingly, and then only to
read not write. Even then only use it to store data that really
doesn't change much.
Thanks for this, not necessarily for my sake, but for others that may
fall into this not-so-obvious trap.
On Dec 7, 2007, at 3:56 PM, Pierre Bernard wrote:
It is important to see the EOEditingContext as a sandbox. It's the
EC that contains your unsaved changes. It's not the "EOF stack"
that is clogged with pending updates. Other clients of the EOF
stack will not even see your local changes until they are committed.
When saving fails over a validation error, you get a chance to
modify your sandbox until it is in a valid state.
This also implies that your EC should preferably have a rather
short lifespan and a limited scope. E.g. it should no live for as
long as your application instance and carry uncommited data between
unrelated bits of code.
I for one consider the session default editing context to be mostly
a convenience for smaller applications. I use it only to load data
that shares the lifespan of the session. And I never ever use this
context for write operations.
Pierre
On Dec 7, 2007, at 5:03 PM, Alan Ward wrote:
The unsaved objects(s) are still in your EOEditingContext and thus
any future attempts to save
will try to save them again (along with any subsequent changes).
The approach that you describe
below is not the best one. What you want to do is to catch the
exception from ec.saveChanges()
and depending on what caused it either a) fix your code to prevent
it happening, b) modify the
EO's in your EC such that they can be saved or c) revert the EC
and abandon the unsaved changes.
If you do none of the above and keep trying to save that
editingContext then you'll just keep getting
the same error as EOF tries to persist your changes to the database.
Alan
On Dec 7, 2007, at 8:48 AM, Greg Lappen wrote:
Hi all,
I just recently ran into an issue where my application tried to
save a new object to the database, the save failed, and every
subsequent save failed with the same error. It seems that
WebObjects maintains a queue of updates/saves to write to the
database, and when one fails, it essentially clogs up the queue
because WO keeps trying to save it eveytime someone calls
saveChanges() on an editing context. What I'd like to do is set
up a global exception handler in my application that runs
whenever an exception is not caught by my code, and in that error
handler I want to reset the whole EnterpriseObject stack - the
cache, the update/save queue, everything - so that other work in
the application can continue and not worry about cache corruption
or anything like that.
Is this possible to do? Anyone know how to do it?
Thanks so much for any help.
Greg
_______________________________________________
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/award%
40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/webobjects-
lists%40houdah.com
This email sent to [EMAIL PROTECTED]
- - -
Houdah Software s. à r. l.
http://www.houdah.com
HoudahGeo: One-stop photo geocoding
HoudahSpot: Powerful Spotlight frontend
_______________________________________________
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/robert.walker%
40bennettig.com
This email sent to [EMAIL PROTECTED]
--
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
