Re: Difference in relationships storage between various storage options (CoreData)
Re: Difference in relationships storage between various storage options (CoreData)
- Subject: Re: Difference in relationships storage between various storage options (CoreData)
- From: Alexander Lamb <email@hidden>
- Date: Thu, 15 Jun 2006 10:44:52 +0200
That's what I suspected, but then it means there is a bug in my code
which prevents the reverse relationship being set.
Thanks,
Alex
--
Alexander Lamb
email@hidden
On Jun 15, 2006, at 8:20 AM, Chris Hanson wrote:
On Jun 14, 2006, at 10:31 PM, Alexander Lamb wrote:
It is marked with it's inverse in the model. But doing a
"setDepartment" doensn't automagically set the inverse, or does
it? At the time of WebObjects it was necessary to do a
"addObjectToBothSidesOfRelationshipWithKey". Is it the same with
CoreData?
So long as -setDepartment: is implemented correctly -- e.g. it
invokes -willChangeValueForKey: and -didChangeValueForKey: as
specified in the documentation -- both the "Employee.department"
relationship and its inverse "Department.employees" relationship
will be maintained automatically.
Similarly, if you either use a properly-implemented accessor method
on Department for the "employees" relationship or manipulate the
result of -mutableSetValueForKey: then both the
"Department.employees" and it inverse "Employee.department"
relationship will be maintained automatically.
There's nothing like -addObject:toBothSidesOfRelationshipWithKey:
necessary in Core Data.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden