Fwd: More CoreData questions...

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

    Begin forwarded message:

    > From: Mike McCabe <mike...>
    > Date: January 16, 2008 11:11:32 AM EST
    > To: Ben Trumbull <trumbull...>
    > 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
    >>
    >
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today