setFetchLimit и sectionNameKeyPath на iPhone OS4 (XCode 3.2.3) вызывают сбои

Question

Ранее на iPhone OS 3.2 с XCode 3.2.2 это работало нормально.

Я создал небольшой тест, чтобы доказать это. Объект NSManagedObject с двумя атрибутами: «group» и «vaue». Обе строки.

При настройке NSFetchedResultsController, который будет использоваться в TableViewController, я настроил setFetchLimit в запросе, и я установил sectionNameKeyPath в «группу», так как я хочу, чтобы результирующие объекты были сгруппированы по разделам.

Предыдущее поведение (ранее iPhone OS 4 и XCode 3.2.3) вернет набор результатов, содержащий максимальное количество объектов, указанных в лимите.

С новой ОС и XCode секции «FecthedResultsController» и numberOfObjects в каждом разделе возвращают ВСЕ значения, которые находятся в постоянном хранилище, игнорируя установленный предел.

Но когда делегат методы пытаются получить доступ к данным, не существует, и это порождает [_PFBatchFaultingArray objectAtIndex]: индекс (X) вне границ (X)», будучи X предел я установил, и в результате чего приложение для сбоя.

Мне кажется, что есть ошибка в SDK при использовании границы и разделы вместе, которые были введены с 3.2.3/OS 4.

Пример задачи:

в группе хранения данных «А», содержащей элементы «3», группа «В», содержащая элементы «2» и группу «С», содержащие элементы «2» (общее количество элементов 7), а предел установлен на 7, все разделы будут возвращены. Если предел установлен менее 7, приложение будет аварийно завершено.

Кто-нибудь еще испытывает эту проблему?

Answer 1

У меня возникло нечто похожее после модернизации.

Я нашел, что добавление вызова для удаления кеша, казалось, решило мою проблему.

[NSFetchedResultsController deleteCacheWithName:@"myCacheName]; 

Надежда, что помогает, Matt

Answer 2

был сбой с одной секции. Решение - это гибрид предложения Мэтта и ответа Дэвида; Я установил cacheName в 0:

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