Hi Dave,
Regarding your comments on ERXEC (which I am using in all my EO's,
or at least all my EO's extend ERXGenericRecord):
I always create new ECs for any task that is going to require editing.
Using Project Wonder's ERXEC makes this particularly painless as it
handles the necessary EC locking automagically.
I have a long running background task. If I do as suggested here:
In the task method itself:
- Create a new ObjectStoreCoordinator (use Wonder OSC
synchronization if you want changes to propogate)
- Create any editing contexts using that single task OSC as a parent
- lock and unlock your ec's manually when working with them
Since I'm using ERXEC, should I be able to get away with NOT locking
and unlocking my ec's manually? What if I don't create a new
ObjectStoreCoordinator for the background task?
Thanks,
Jeff
On Aug 1, 2008, at 10:22 PM, David LeBer wrote:
On 1-Aug-08, at 8:33 PM, Gustavo Pizano wrote:
Hello everyone, I just wanted to ask a noob question. Everywhere I
look I see about the EditingConext, as I know, it function its to
hold instances of the EO's so they can interact each other and so.
in the tutorials and the documentations, they talk most of the part
about the defaultEditingContext, from the session, or the
apllication, so my question is, when its necessary to use the
defaultEditingContext, and to create a new one?.
This thing about the EditingContext its spining my head a little.
Tutorials generally don't use anything other than the
defaultEditingContext because it adds a layer of complexity that the
authors (I assume) feel will detract from the core purpose of the
tutorial.
However, this tends to give beginners a false impression of how most
real-world applications are written and also fails to demonstrate
the pitfalls of a single EC design.
Lets take a (completely contrived) example:
Your application is using the defaultEditingContext. Your user
enters a form that creates a new EO. Half way through they decide to
abort and hit the back button a couple of times and go somewhere
else in the site.
The defaultEditingContext is now dirtied with that new EO. If the
user later performs any action that calls saveChanges on the
defaultEC it will try and commit the EO, it might fail giving your
user a completely unexplainable validation error, or it might
succeed saving unwanted and probably invalid data.
So my general rule of thumb is to never use the
defaultEditingContext for any edit actions. I always create new ECs
for any task that is going to require editing.
Using Project Wonder's ERXEC makes this particularly painless as it
handles the necessary EC locking automagically.
Other options are documented here: <http://wiki.objectstyle.org/confluence/display/WO/EOF-Using+EOF-Context+and+Database+Locking
>
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
twitter: http://twitter.com/rebeld
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jeffandmonica%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
