Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread Display Modes
Old Aug 15, 2006, 09:44 AM   #1
macrumors 6502a
Join Date: Jun 2005
Location: West-Europe
unrelating relationships

I have a to-many relationship from A to B and a to-many from B to A.

I use setvalue:forkey: to change the to-many AtoB, which works fine. Previously included links are removed, new links to A are added. However the links from A to B are not removed. So A still thinks it has a relationship with B, when it shouldn't. I thought the entire point of bidirectional relationships was to ensure data integrity, and to keep the relationships up to date. so that each side knows if it belongs to each other or not.

From the NSManagedobject class reference:
Given a collection object and a key that identifies a to-many relationship, relates the objects contained in the collection to the receiver, unrelating previously related objects if there were any.

How can I ensure that if a relationship in one direction is removed, the relationship in the other direction is also broken or removed?
MrFusion is offline   0 Reply With Quote

MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
What do you think about long-distance relationships? sunnysweet Community Discussion 71 Jan 10, 2014 07:10 AM
C and Objective-C relationships nashyo iPhone/iPad Programming 16 Jan 21, 2013 05:48 AM
How have your political views affected your relationships with others this year? glocke12 Politics, Religion, Social Issues 144 Oct 17, 2012 06:55 PM
So how progressive are you? Relationships niuniu Politics, Religion, Social Issues 65 Aug 13, 2012 08:20 PM

Forum Jump

All times are GMT -5. The time now is 06:03 PM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2015, MacRumors.com, LLC