On Dec 10, 2008, at 22:36, Nathan Vander Wilt wrote:
I'm trying to port my model code to use Core Data. My model is
something like this:
I have a Company. It has two to-many relationships, currentEmployees
and previousEmployees which are naturally both to Employees.
Employees have a to-one relationship to the Company that is the
inverse of both the currentEmployees and previousEmployees. That is,
the employee (records) belong to the Company regardless of current/
previous "status".
I also have a Consultant. It has a to-many relationship to
interestingEmployees. Nobody talking to an Employee needs to have
access to the Consultant, so there is no inverse relationship.
I have two problems with this model. When I compile it, I get a
warning:
Consultant.interestingEmployees -- to-many relationship does not
have an inverse: this is an advanced setting (no object can be in
multiple destinations for a specific relationship)
This error doesn't make sense to me. Is it trying to say an object
can only "belong" to one to-many relationship?
The other problem is that I do want to define an inverse for
Employee.company, but I can't set it to *both*
Company.currentEmployees and .previousEmployees. I think the answer
is to maintain the Employee.company relationship field myself
without any inverse, but then I get two more warnings for each of
the Company to-many relationships.
There's no compelling reason why relationships should necessarily have
an inverse (and there's a build setting to turn off the warning now).
You mainly have to be careful that when you delete or insert an
Employee object, you make sure you adjust the non-inversed
relationships to match.
Based on your description, I'd suggest having an Employees to-many
relationship on Company objects, and a Company relationship on
Employee objects as the inverse. Then define your other to-many
relationships (currentEmployees, previousEmployees and
interestingEmployees) as having no inverses. That, in practical terms,
will allow you to navigate all the relationships in both directions.
You *could* use attributes instead of relationships, though this would
likely mean you'd need to get hold of the subsets (like current or
previous employees) via fetches. There's nothing wrong with that,
except that it involves an extra step and there might be performance
considerations.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
