Re: locking editing context when removing item
Re: locking editing context when removing item
- Subject: Re: locking editing context when removing item
- From: "Jonathan Fleming" <email@hidden>
- Date: Tue, 17 Feb 2004 17:03:34 +0000
Ok Jonathan
Here's what's happening: (code is below)
firstly when deleteTbJobPicture() Method is called the user wants to delete
an item in a WORepitition and the item is removed from the ec of that item
(in this case tbJobPicture), the app pauses giving the user a chance to
revert or cancel their action in case they are making a mistake, but if they
then continue the Method OkFullDeletion() is called and commits the changes.
Now going by what you are telling me , I'm doing something wrong but I have
been using this setup since I first learnt how to do a delete with
webObjects and it has been fine - even now, however, what I noticed in those
early days was that when I tried to remove something from its own ec such as
tbJobPicture.editingContext(), but not yet saved, and then moved to another
page in the app and did an actual save elsewhere with what I later learned
was the session().defaultEditingContext(), I found that all the items I had
removed earlier from within another page was fully deleted and actually
saved to the database.
Now, I know you say that this don't seem right but it happens and it hasn't
given me a problem. Regardless I'm only just now getting into using other
ec's apart from the default and have been locking everything except for this
type of delete code I threw together in my very green horn days, only now
that I'm querying and trying to tidy up my apps, and going by your judgement
i'm once again in a slight state of confusion... Good 'ol WebObjects :^)
So doc, what's the prognosis? To me it seems that saving with the default ec
rules all.
Jonathan F :^)
ps. those early learnings came from the Author app that is demonstrated in
the documentations.
/*-------------- Deletion Of Enterprise Objects ----------------*/
public WOComponent deleteTbJobPicture() {
// set the tbJobPicture to edit to the one the user selected
tbJobPicture = tbJobPictureItem;
// get editing context from tbJobPicture object
EOEditingContext ec = tbJobPicture.editingContext();
// delete tbJobPicture from its editing context
ec.deleteObject(tbJobPicture);
// remove object from relationship
tbJob.removeObjectFromBothSidesOfRelationshipWithKey(tbJobPicture,
"tbJobPictures");
return context().page();
}
/*------------------*/
public WOComponent OkFullDeletion() {
// get editing context
EOEditingContext ec = session().defaultEditingContext();
// method to delete the Thumb & Jpeg images
deleteFileSystemImages();
// save changes made in editing context to object store
ec.saveChanges();
return context().page();
}
/*------------------------------------------------------------*/
From: Jonathan Rochkind <email@hidden>
To: "Jonathan Fleming" <email@hidden>
CC: email@hidden
Subject: Re: locking editing context when removing item
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
_________________________________________________________________
Tired of 56k? Get a FREE BT Broadband connection
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.