CoreData countForFetchRequest indique 'entité non trouvée'

Question

Je rencontre un problème étrange lorsque je tente de compter les entités dans un contexte d'objet géré.

- (NSUInteger)countEntity:(NSString *)entityName 
       inContext:(NSManagedObjectContext *)context{ 

    NSFetchRequest *request = [[NSFetchRequest alloc] init]; 
    NSEntityDescription *entity = [NSEntityDescription entityForName:entityName      
                inManagedObjectContext:context]; 
    [request setEntity:entity]; 
    [request setIncludesSubentities:NO]; 
    NSError *error = nil; 
    NSUInteger count = [context countForFetchRequest:request error:&error]; 
    [request release]; 
    return count; 
} 

La ligne:

NSUInteger count = [context countForFetchRequest:request error:&error]; 

jette un NSInternalInconsistencyException reason: 'entity not found'

Changer à:

NSUInteger count = [[context executeFetchRequest:request error:&error] count]; 

fonctionne sans aucun problème.

Je suis à la perte ici. Des idées?

Merci!

/Oskar

Answer 1

Courir dans ceci aujourd'hui. Commencé à se produire lorsque j'ai introduit un deuxième magasin persistant.Avez-vous plus d'un magasin dans le moc? -Ken

Answer 2

Vérifiez plusieurs choses:

1. Quelle est la valeur de error après le premier appel? La raison pour laquelle vous passez dans cet objet est d'obtenir des informations lorsque les choses tournent mal. Quelle est la valeur de [request entity] après le premier appel? Je suis peut-être complètement éteint, mais je me souviens très vaguement de quelque chose à propos d'une demande d'un coup unique: une fois que vous l'avez exécuté, vous devez réinitialiser tous les différents champs avant de pouvoir l'exécuter à nouveau. Assurez-vous que toutes les propriétés de votre demande sont toujours valides après le premier appel, ou mieux encore créez une deuxième instance NSFetchRequest pour effectuer le second appel.
2. Dans la même veine, que se passe-t-il si vous commentez le premier appel? Si vous changez l'ordre des appels? Le résultat de l'un pourrait en affecter un autre.

Answer 3

Le problème que vous rencontrez est dû à une mauvaise utilisation de countForFetchRequest: erreur:. En effet, dans votre fragment de code, vous devez d'abord exécuter la requête d'extraction en utilisant executeFetchRequest: error, puis procéder à l'utilisation de countForFetchRequest: error :.

De la documentation de la méthode:

Renvoie le nombre d'objets a donné FETCH aurait retourné si elle avait été adoptée à executeFetchRequest: erreur :.

Par conséquent, vous ne devez PAS exécuter la requête d'extraction avant d'appeler countForFetchRequest: error :.

Answer 4

Je soupçonne que entity est nil (c.-à-context est nul ou ne dispose pas d'un coordonnateur de stockage permanent configuré correctement avec un modèle d'objet géré contenant votre entité, ou si vous avez mal orthographié le nom de l'entité quelque part dans le modèle d'objet ou dans l'appel code). Vérifiez que entity n'est pas nil après l'appel à +[NSEntityDescription entityForName:inManagedObjectContext:].

Answer 5

J'ai exécuté votre méthode countEntity: dans un de mes propres projets et il s'est bien déroulé. La seule façon dont je pouvais l'obtenir pour lancer une exception ("_countWithNoChangesForRequest: error: Une requête de recherche doit avoir une entité.") Était quand j'ai mis-mis en majuscule le nom de l'entité (widgets à la place Widgets). Donc, vous pourriez vouloir enquêter dans cette direction.

Answer 6

Pour ce que ça vaut Je viens à travers un bug similaire où executeFetchRequest:error et countForFetchRequest:error: ne sont pas d'accord sur le nombre d'objets dans la requête d'extraction.

Le scénario est que j'ai imbriqué NSManagedObjectContexts avec un contexte racine de type NSPrivateQueueConcurrencyType (pour l'enregistrement sur le disque) soutenu par un magasin persistant et un enfant de ce NSMainQueueConcurrencyType avec le type (pour une utilisation par l'IUG). (Oui, j'utilise MagicalRecord)

J'ai un ViewController en écoute NSManagedObjectContextDidSaveNotification du contexte 'main'. Lorsque cette notification se déclenche, la méthode countForFetchRequest:error: n'inclut pas les modifications apportées au contexte qui n'ont pas été enregistrées dans le contexte racine parent. executeFetchRequest:error renvoie cependant l'ensemble attendu d'objets.

Bit wierd.