Fwd: More CoreData questions...

FROM : Mike McCabe
DATE : Wed Jan 16 17:58:45 2008

Oops... Forgot to send to the list too... :)

Begin forwarded message:

> From: Mike McCabe <<email_removed>>
> Date: January 16, 2008 11:11:32 AM EST
> To: Ben Trumbull <<email_removed>>
> Subject: Re: More CoreData questions...
>
>
> On Jan 15, 2008, at 9:20 PM, Ben Trumbull wrote:
>

>> Mike,
>>

>>> When I get to the first table that I need to recreate a one-to 
>>> many relationship I find that if after specifying the first 
>>> connection if I don't force a save of the managedObjectContext 
>>> then the next fetch that is for the index comes up with 0 
>>> results.  Here is part of my
>>> code...

>>
>> It's a little hard to tell from the code excerpt that omits the 
>> definition of the fetch request, the relationships involved, etc. 
>> but my guess is that you're encountering a limitation of the in 
>> memory filtering that is applied to uncommitted changes.
>>

>
> The fetch request is just a simple one that uses the Predicate... 
> People_ID == $FETCH_ID
>

>> The -initWithEntity:insertIntoManagedObjectContext: method creates 
>> a new instance that is added to the list of pending insertions. 
>> Those are committed during the next save.
>>
>> Executed a fetch request always goes to disk (searches the 
>> database) but the newly inserted objects haven't actually been 
>> saved yet.  So the database returns 0 results.  The 
>> NSManagedObjectContext notices it has a bunch of unsaved changes, 
>> and tries to adjust the results from the database query to 
>> accommodate the changes that have not yet been committed.
>>
>> This adjustment is done by applying the same predicate from the 
>> fetch request to each dirtied (unsaved) managed object of the 
>> entity you're fetching.  If the predicate matches the unsaved 
>> changes then inserted objects are added to the result set, deleted 
>> objects removed, etc.
>>
>> Since the filtering is only done to managed objects of the entity 
>> you're fetching, it's possible to fail to notice that changes to 
>> related objects would have affected the predicate.
>>
>> I infer from the excerpt that you're fetching Teachers.  The 
>> teacher objects ought to be marked dirty by:
>>  [t1 addClasses_TaughtObject:c];
>>

>
> The fetch request is shown above... People_ID is an int32 type 
> attribute with the indexed box checked...
>
> The addClasses_TaughtObject is being generated by the CoreData 
> system.  It's definition shows up in the People.h file as:
>
> @interface People (CoreDataGeneratedAccessors)
> - (void)addClasses_TaughtObject:(Classes *)value;
> .... Others that seem to be related to the Many type of 
> relationship...
> @end
>
> Is there a better way to do this?  I am very new to Cocoa and 
> CoreData...  I have I think read most of the documentation that is 
> available and have watched at least all of the CoreData videos from 
> the previous 4 WWDC's that I can get access to on the ADC on iTunes 
> site.  I am a premier developer so I have all of the WWDC 07 videos...
>
> Thanks for taking the time to respond...
>
> Mike
>

>> so examining your fetch request and your custom setter code would 
>> be helpful.
>> --
>>
>> -Ben
>>

>