Re: Managing relationships by fetching related objects within subclass of NSManagedObject
Re: Managing relationships by fetching related objects within subclass of NSManagedObject
- Subject: Re: Managing relationships by fetching related objects within subclass of NSManagedObject
- From: Keary Suska <email@hidden>
- Date: Sat, 09 Feb 2013 23:26:18 -0700
On Feb 9, 2013, at 8:28 PM, Devarshi Kulshreshtha wrote:
> Hi Keary,
>
> Thnx for your reply :-)
>
> Regarding your answer to my 2nd query, I understand that once I map the newEmployee to company, the inverse relationship from company to employee will be by default, no need for me to map it back. So in that case should I do a check, say- if( aCompanyObject.employee == nil) then only map the relationship else not?
The relationships need to be modeled in both directions (i.e. specified in the Managed Object Model), but of course Core Data will handle settings inverse relationships automatically.
That being said, there is no good reason that setting a relationship would fail, so checking is only good for test cases really. If relationships aren;t being set it means something more fundamental if probably wrong.
Also, "Company" to "Employee" is one-to-many, so you would check for an empty NSSet. At least it should be more reliable: [aCompanyObject.employee count] > 0
> Also can you elaborate with a simple example about how to be watchful of fault-firing?
Maybe more simply put, you should not model relationships that you don't want Core data to manage--that is thast you want to manage manually. You could potentially put the NSManagedObjectContext in an inconsistent state and then it will throw exceptions. Also if you want to manage a relationship manually, you also have to manually manage the integrity of the object graph for these relationships. You won't have to worry about faulting if Core data doesn't think it needs to manage the relationship.
> On Sun, Feb 10, 2013 at 12:16 AM, Keary Suska <email@hidden> wrote:
>
> On Feb 9, 2013, at 10:20 AM, Devarshi Kulshreshtha wrote:
>
> > Say I have an employee entity and a company entity in core data.
> >
> > So employee and company are related to each other like this:
> >
> > Employee <<---> Company
> >
> > Now I am trying to right a manageRelationships method in each class,
> > something like this:
> >
> > @interface Employee : NSManagedObject
> > - (void)manageRelationships;
> > @property (nonatomic, retain) Company *company; // for relationship
> > @property (nonatomic, retain) NSNumber *companyId; // acts as foreign
> > key
> > @end
> >
> > @implementation Employee
> > @dynamic company;
> > @dynamic companyId;
> > - (void)manageRelationships
> > {
> > // prepare a predicate as @"companyId == %@",self.companyId
> >
> > // execute a fetch request against Company entity
> >
> > // map relationship using self.company = retrievedCompanyObject
> > }
> >
> > Now I have few questions:
> >
> > 1. Is it safe to fire fetch request and map a relationship, as implemented
> > above, within a subclass of NSManagedObject?
>
> Possibly, though you have to be watchful of fault-firing.
>
> > 2. Is their any better way to achieve it? (Idea behind above approach is- I
> > will be calling above method on each created managed object so that it
> > automatically manages and maps all associated relationships)
>
> Well, Core Data manages modeled relationships for you given a minimal relationship. For instance, when creating a new Employee, simply setting newEmployee.companyRelationship = companyObject will establish also the to-many side of the relationship as long as both are modeled. You can also do the reverse, inserting the Employee object into the Company to-many relationship collection (in a KVO-compliant way). Note that this is all fully and well documented in the Core Data docs.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden