setFetchLimit et sectionNameKeyPath sur iPhone OS4 (XCode 3.2.3) Cause accident

Question

Auparavant, sur l'iPhone OS 3.2 avec XCode 3.2.2 utilisés pour fonctionner correctement.

J'ai créé un petit test pour le prouver. Un objet NSManagedObject avec 2 attributs, "group" et "vaue". Les deux chaînes. Lors de la configuration d'un NSFetchedResultsController à utiliser dans TableViewController, je configure setFetchLimit sur la requête et je mets la sectionNameKeyPath à "group", puisque je veux que les entités de résultat soient groupées en sections.

comportement antérieur (antérieur iPhone OS 4 et XCode 3.2.3) retournera l'ensemble de résultats de ENTITES contenant la quantité maximale d'entités spécifiées dans la limite. Avec les nouveaux OS et XCode, les sections "FecthedResultsController" et "numberOfObjects" de chaque section renvoient TOUTES les valeurs qui se trouvent dans le stockage persistant, en ignorant la limite définie.

Mais quand les méthodes de délégués tentent d'accéder aux données, il est pas là, et il génère un [_PFBatchFaultingArray objectAtIndex:]: index (X) au-delà des limites (X) », étant X la limite que je mets et cause l'application à planter.

Il me semble qu'il ya un bogue dans le SDK lorsque vous utilisez les limites et les sections ensemble qui a été mis en place depuis 3.2.3/OS 4.

Un exemple du problème:

ayant dans le groupe de magasins de données "A" contenant "3" articles, groupe "B" contenant "2" articles et groupe "C" contenant "2" articles (étant le nombre total d'articles 7), et la limite est fixée à 7, toutes les sections seront retournées. Si la limite est inférieure à 7, l'application se bloque.

Toute autre personne connaît ce problème?

Answer 1

Je ressentais quelque chose de vaguement similaire après la mise à niveau.

Je trouve l'ajout d'un appel à supprimer le cache semblait résoudre mon problème.

[NSFetchedResultsController deleteCacheWithName:@"myCacheName]; 

Espoir qui aide, Matt

Answer 2

plantait avec une seule section. La solution est un hybride de la suggestion de Matt et de la réponse de David; J'ai mis le cacheName à zéro dans:

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