Fwd: More CoreData questions...
Fwd: More CoreData questions...
- Subject: Fwd: More CoreData questions...
- From: Mike McCabe <email@hidden>
- Date: Wed, 16 Jan 2008 11:58:45 -0500
Oops... Forgot to send to the list too... :)
Begin forwarded message:
From: Mike McCabe <email@hidden>
Date: January 16, 2008 11:11:32 AM EST
To: Ben Trumbull <email@hidden>
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
_______________________________________________
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