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

Thread Tools Search this Thread Display Modes
Old Aug 15, 2006, 10: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 08:10 AM
C and Objective-C relationships nashyo iPhone/iPad Programming 16 Jan 21, 2013 06:48 AM
How have your political views affected your relationships with others this year? glocke12 Politics, Religion, Social Issues 144 Oct 17, 2012 07:55 PM
So how progressive are you? Relationships niuniu Politics, Religion, Social Issues 65 Aug 13, 2012 09:20 PM

Forum Jump

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

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

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