Coredata sur iPhone, setFetchBatchSize et setPropertiesToFetch en une seule demande

Question

J'écris une application iPhone basée sur Coredata qui affiche des recettes. Pour améliorer les performances, lorsque vous les affichez dans un TableView, je veux activer le traitement par lots (-setFetchBatchSize :) et récupérer uniquement l'attribut "name" (-setPropertiesToFetch :). Lorsque j'allume les deux, cela ne fonctionne pas et la liste est vide. Dès que je commente l'une des lignes marquées dans le code ci-dessous, cela fonctionne très bien.

Qu'est-ce qui me manque ici? Est-ce impossible d'avoir les deux?

NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init] autorelease]; 
[fetchRequest setEntity:[NSEntityDescription entityForName:@"Rezept" inManagedObjectContext:chk_context]]; 
// *snip* 

//BATCHING 
[fetchRequest setFetchBatchSize:25]; 

NSDictionary *entityProperties = [[NSEntityDescription entityForName:@"Rezept" inManagedObjectContext:chk_context] propertiesByName]; 

//PROPERTIES 
[fetchRequest setPropertiesToFetch:[NSArray arrayWithObject:[entityProperties objectForKey:@"name"]]]; 

Answer 1

Mise à jour: "NSUnderlyingException = La base de données apparaît corrompue (clé primaire invalide);" Quand je NSLog l'erreur après

[fetchedResultsController performFetch:&error]; 

je reçois. Mais je ne sais pas ce que cela signifie et ce que cela a à voir avec l'activation des deux méthodes.

Answer 2

On dirait que vous avez trouvé un bug dans CoreData. Vous pouvez vérifier avec certitude en activant la journalisation SQL - Je suppose que l'activation des deux options génère un SQL légèrement invalide.

L'option que vous souhaitez utiliser est "com.apple.CoreData.SQLDebug 1" - vous pouvez spécifier ceci à partir de la ligne de commande, ou définir la valeur par défaut de votre programme.

-Wil

Answer 3

Hunter vous pouvez utiliser com.apple.CoreData.SQLDebug 1 sur le téléphone, mais pas en utilisant le simulateur

Answer 4

Je suis loin d'être un expert de données de base, mais je suis arrivé à travailler avec succès ce dans ma situation. Je pense que le "conflit" entre setFetchBatchSize et setPropertiesToFetch est plus un effet secondaire de la façon dont les données de base fonctionnent et pas un bogue en soi.

Dans mon cas, j'ai fait deux extractions. Dans le premier, le type de résultat a été défini sur NSManagedObjectResultType et j'ai utilisé setFetchBatchSize pour limiter la quantité de données activement mises en mémoire. Dans le second fetch, je remplis un tableau de titres basé sur un seul attribut et définit le type de résultat sur NSDictionaryResultType et fetchBatchSize sur 0 (infini). Basé sur des tests, ce scénario fonctionne parfaitement. Tous les enregistrements de l'extraction initiale (avec les managedObjects réels) sont faussés et limités en mémoire par fetchBatchSize. Le second fetch retourne un dictionnaire simple de titres. Cela prend beaucoup moins de mémoire que d'itérer dans tous les managedObjects actuels pour accéder à l'attribut title. Il est logique que le second fetch ait besoin de fetchBatchSize désactivé car il renvoie le dictionnaire entièrement rempli sous la forme d'un résultat unique et le traitement par lot ne serait pas approprié. Je ne suis pas sûr d'être 100% clair ici (la terminologie de base de données est un peu arcane ...) mais l'essentiel est que je pense que tout fonctionne comme prévu.