Re: locking editing context when removing item
Re: locking editing context when removing item
- Subject: Re: locking editing context when removing item
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 16 Feb 2004 12:36:31 -0600
deleted, fine. But unless you call saveChanges() on ecTb, nothing
is going to happen.
Correct. This is done on purpose
Once you call saveChanges on ecTb,
the saveChages is called with the defaultEditingContext (referenced
in this example as ec)
Again, this doens't make sense to me. This code:
EOEditingContext ec1; //assume exists
EOEditingContext ec2; //assume exists
[1: ] ec1.deleteObject( someObject );
[2: ] ec2.saveChanges();
Will _never_ commit anything to the db, regardless of the 'nest'
relationship of the ECs. Line 1 tells ec1 to register someObject as
deleted. ec2, at this point, regardless of whether ec1 is nested in
ec2, does not know about this fact. When you call ec2.saveChanges(),
all the changes ec2 _knows_ about will be committed to the db (or a
parent object store of some sort)---but ec2 doesn't know about that
'delete'.
If ec1 is nested in ec2, then:
ec1.deleteObject( someObject ); //ec1 knows that someObject is
registered for deletion
ec1.saveChanges(); //ec1 has 'saved' it's changes---but since it's a
nested EC, the way it saves them is just by passing them on to it's
parent EC. _Now_, after ec1.saveChanges(), it's parent, ec2, knows
about the change.
ec2.saveChanges(); //now ec2 commits all the changes it knows about,
which include the deleted object, because of the above line.
the change is either committed to the db, or again registered with
a parent EC if ecTb is a nested EC.
Tell me if i'm wrong, but ain't all other editing contexts
automatically nested in the defaultEditingContext?
Okay, you're wrong. If you create an EC like:
new EOEditingContext();
Then it is not nested in any other EC, it is just an ordinary EC,
which under standard configuration will commit changes to the db.
If, on the other hand, you create an EC like:
new EOEditingContext( someOtherEC );
then that new EC is 'nested' in someOtherEC. someOtherEC could be
the session.defaultEditingContext(), or it could hypothetically be
any EC at all. In this 'nested' case, calling saveChanges() will just
pass the changes on to the 'parent' EC (someOtherEC), it will not
commit them to the db.
Hope this helps,
--Jonathan
I use this sort of setup a lot for one reason or another :^/
Regardless I shall go around my app and now lock all my deletes as
this is the only place that i don't lock. Just didn't think it was
necassary, but thinking about it, you're updating, so...
Jonathan :^)
Hope this helps,
--Jonathan
At 2:39 PM +0000 2/16/04, Jonathan Fleming wrote:
Just checking really... do I need to put a lock on the ec when
removing an item from its own ec? So would this code be wrong or
cause problems?:
// the default ec is instatiated somewhere else earlier in the code
EOEditingContext ec = session().defaultEditingContext();
....................
// remove tbAddressAdminUser from queryResults
queryResults.removeObject(tbAddressAdminUser);
// get objects editing context
EOEditingContext ecTb =
tbAddressAdminUser.editingContext();
// remove tbAddressAdminUser from object graph
ecTb.deleteObject(tbAddressAdminUser);
// save changes made in editing context to
object store
....................
// the save is done later with the default ec
ec.saveChanges();
Advanced Thanks
Jonathan :^)
_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_________________________________________________________________
Sign-up for a FREE BT Broadband connection today!
http://www.msn.co.uk/specials/btbroadband
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.