setFetchLimit and sectionNameKeyPath on iPhone OS4 (XCode 3.2.3) cause crash

Previously, on iPhone OS 3.2 with XCode 3.2.2 this used to work fine.

I have created a small test to prove it. An NSManagedObject with 2 attributes, "group" and "vaue". Both strings.

When setting up an NSFetchedResultsController to be used in the TableViewController, I set up the setFetchLimit on the request and I set the sectionNameKeyPath to "group", since I want the result entities to be grouped in sections.

The former behaviour (prior iPhone OS 4 and XCode 3.2.3) would return the resultset of entites containing the maximum amount of entities specified in the limit.

With the new OS and XCode, the FecthedResultsController "sections" and numberOfObjects in each section return ALL the values that are in the persistent store, ignoring the set Limit.

But when the delegate methods try to access the data, it's not there, and it generates a [_PFBatchFaultingArray objectAtIndex:]: index (X) beyond bounds (X)', being X the limit I set, and causing the application to crash.

It seems to me that there is a bug in the SDK when using the limits and the sections together that has been introduced since 3.2.3/OS 4.

An example of the problem:

having in the data store group "A" containing "3" items, group "B" containing "2" items and group "C" containing "2" items (being the total number of items 7), and the limit开发者_开发知识库 is set to 7, all the sections will be returned. If the limit is set to less than 7, the application will crash.

Anyone else is experiencing this issue?

I was experiencing something vaguely similar after upgrading.

I found adding a call to delete the cache seemed to solve my problem.

[NSFetchedResultsController deleteCacheWithName:@"myCacheName];

Hope that helps, Matt

Was crashing with a single section. Solution is a hybrid of Matt's suggestion and David's reply; I set the cacheName to nil in:

- (id)initWithFetchRequest:managedObjectContext:sectionNameKeyPath:**strong text**cacheName:**strong text**