Re: removeObjectFromBothSidesOfRelationshipWithKey() question
Re: removeObjectFromBothSidesOfRelationshipWithKey() question
- Subject: Re: removeObjectFromBothSidesOfRelationshipWithKey() question
- From: David LeBer <email@hidden>
- Date: Tue, 27 Oct 2009 20:15:42 -0400
On 2009-10-27, at 7:52 PM, Chuck Hill wrote:
On Oct 27, 2009, at 4:40 PM, Lon Varscsak wrote:
Try:
Create an Order and OrderItem and insert both into an editing
context.
Then add the item to the order using
order.addObjectToBothSidesOfRelationshipWithKey(item, "items").
Then call editingContext.processRecentChanges()
Then removeObjectFromBothSidesOfRelationshipWithKey(item, "items")
to remove the item.
Then save the editing context.
Here is the docs on that method:
Forces this EOEditingContext to process pending insertions,
deletions, and updates. Normally, when objects are changed, the
processing of the changes is deferred until the end of the current
event. At that point, an EOEditingContext moves objects to the
inserted, updated, and deleted lists, delete propagation is
performed, undos are registered, and
ObjectsChangedInStoreNotification and
ObjectsChangedInEditingContextNotification are posted. You can use
this method to explicitly force changes to be processed. An
EOEditingContext automatically invokes this method on itself before
performing certain operations such as saveChanges. This method does
nothing in Java Client applications.
I'm struggling with how to describe why that works. :P
It should not work. processRecentChanges() is called during
saveChanges() so it should not affect the item getting deleted. My
feeling is that it not getting deleted after initial insertion is a
bug.
I can confirm that calling ec.processRecentChanges() in between the
addObject... and removeObject... calls does work. Though I don't know
why at this point.
It's been a long week and it's only Tuesday. My understanding
(although I'm sure Chuck will correct me) is that that delete
you're expecting to happen doesn't actually happen until the end of
the event loop (at which time the editingContext's
processRecentChanges method is called). Since you're doing two
actions to the same relationship EOF loses the ability to know what
the right thing to do in that situation (I can't remember the
details as to why this is though...it made sense to me at one
point :D).
Maybe you are thinking of needing to call processRecentChanges() so
that the contents of relationships appear correctly in the UI before
saveChanges is called.
There aren't many times where you're going to do what you describe
(at least in my experience). Generally a user is going to insert/
modify a record in one RR loop and then delete it in another and
you wouldn't see what you're experiencing. However, when the time
arises that you need to do that (for whatever reason) calling
processRecentChanges after my first set of changes (in your case an
insert) will make it so that EOF will automatically do the right
thing for the second set of changes (in your case a delete).
I'm trying to help...but wait for Chuck Hill's response before you
commit that to memory. :P
Done. :-)
Chuck
On Tue, Oct 27, 2009 at 4:20 PM, Ricardo J. Parada
<email@hidden> wrote:
Resending with some typos fixed... :-)
Hi,
Let's say you have to-many relationship between two entities:
Order <-->> OrderItem. The to-many relationship is called "items"
and "Owns Desintation" is checked.
Test #1: Create an Order and OrderItem and insert both into an
editing context. Then add the item to the order using
order.addObjectToBothSidesOfRelationshipWithKey(item, "items").
Then removeObjectFromBothSidesOfRelationshipWithKey(item, "items")
to remove the item. Then save the editing context.
Result: EOF attempts to save both the order and the orphan item.
Expected Result: I thought EOF would only attempt to save the
order but not the item removed from the "items" to-many.
Test #2: Fetch an existing order with one item from the database.
Then order.removeObjectFromBothSidesOfRelationshipWithKey(item,
"items"). Save the editing context.
Result: EOF deletes the item that was removed from the "items" to-
many.
Is this how it's supposed to work?
Thanks,
Ricardo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
;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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden