[Résolu] core data erreur à l'enregistrement
berfis
Membre
Bonjour,
Je me casse la tête depuis des heures sur une erreur probablement située à un endroit auquel je ne pense pas.
J'ai une application qui crée des documents Core Data et je migre de temps en temps sur un nouveau modèle. La migration se passe bien, et je peux modifier et enregistrer des documents issus du modèle antérieur. Mais contre toute attente, l'application plante quand je crée et que j'essaie d'enregistrer un nouveau document.
J'ai d'abord ce warning:
warning: could not load any Objective-C class information from the dyld shared cache. This will significantly reduce the quality of type information available.
Si, dans le debugger, je choisis de continuer, l'application se plante vraiment:
2016-09-28 19:20:10.544 Demiurge[6222:2976966] Cannot perform operation since entity with name '(null)' cannot be found
" La doc indique comme solution possible qu'un contrôleur ne soit pas en mode "Entity". J'ai vérifié mais ils ont tous l'air OK.
" Il pourrait s'agir d'un binding sur une propriété qui n'existe plus, mais j'aurais le message "is not KVC-compliant for the key "truc".
" Les Zombies m'indiqueraient si je tentais de m'adresser à un objet qui n'existe plus.
"J'ai vérifié si le modèle ne contenait pas des conditions de validation fautives, mais là encore CD me donnerait un autre message.
ça plante ici:
-(BOOL)configurePersistentStoreCoordinatorForURL: (NSURL *)url ofType: (NSString *)fileType modelConfiguration: (NSString *)configuration storeOptions: (NSDictionary *)storeOptions error: (NSError **)error
{
NSMutableDictionary *options = (storeOptions != nil) ? [storeOptions mutableCopy] : [NSMutableDictionary new];
options[NSMigratePersistentStoresAutomaticallyOption] = @(YES);
options[NSInferMappingModelAutomaticallyOption] = @(YES);
return [super configurePersistentStoreCoordinatorForURL: url ofType: fileType modelConfiguration: configuration storeOptions: options error: error];
}
plus précisément à [super configurePersistentStoreCoordinatorForURL:...]
Je marche en plein brouillard. L'application compte dix modèles consécutifs, aucun n'a jamais posé problème. Je ne suis même pas sûr que le dernier soit en cause.
Avez-vous des pistes à me suggérer pour résoudre ce problème ?
Merci.
Réponses
http://nshipster.com/launch-arguments-and-environment-variables/
ça te permettra peut-être de savoir quelle opération il n'arrive pas à conduire.
D'après le warning directement j'aurai fait un clean + effacer les DerivedData.
Mais je pense que ça tu l'as deÌjaÌ€ fait...
Oui, Clean, effacer Derived data, redémarré Xcode, redémarré le Mac même.
J'ai un
dans le Debug Navigator. J'ai googlé avec ça, et je tombe sur ceci qui parle d'un bug récurrent dans Xcode. Solution proposée: rebâtir tout le projet... je renâcle un peu...
Je ne suis pas sûr que ton problème soit le même que celui qui est exposé, mais la solution proposée est d'aller modifier Info.plist pour fixer le bon type de stockage Core Data.
Info.plist était une bonne idée, mais ce document est correct (1 seul type de document, binary).
Ca plante toujours.
Non, en fait ça plante de plus en plus. Je connais cette situation, où de manipulation en manipulation, je finis par bousiller un projet pour un détail oublié...
Là , Xcode me lance un "Warning: The Copy Bundle Resources build phase contains this target's Info.plist file 'Demiurge/Info.plist'.
Bah oui, j'ai bien un fichier "Demiurge/Info.plist"... et alors? il me semble nécessaire, il est là , donc pourquoi ce warning?
info.plist ne devrait pas être dans la Copy Bundle Resources build phase...
Il n'y est plus. Ca ne change rien.
Bon, j'ai trouvé: un binding laissé sur le file owner's managedObjectContext pour un appayController qui ne gérait pas d'entités, mais de simples NSMutableDictionaries...
Je n'ai jamais voulu gérer d'entités avec ce contrôleur, mais j'avais besoin tout de même d'une référence au contexte. ça a marché tant que je modifiais des fichiers existants, mais ça plantait lors de la création d'un nouveau document.
Visiblement, qu'un contrôleur gère ou non des entités, le fait qu'il soit relié au ManagedObjectContext suffit à le déclarer comme un contrôleur d'entités... J'ai dû louper un passage de la doc, car finalement leur conseil de vérifier si le contrôleur gérait bien des entités était correct.
Je me suis aperçu de cela en rebâtissant tout le projet à partir d'une version fonctionnelle, et en ajoutant les transformations une à une. C'était fastidieux, mais ça m'a permis de repenser mon modèle et d'aboutir à une meilleure conception.
A quelque chose malheur est bon...
Merci à Céroce et Pyroh pour leurs réponses.
Ah ben au moins t'as trouveÌ et nous on eÌvitera de faire l'erreur
Merci beaucoup berfis, j'avais exactement le même problème mais ne parvenais pas à trouver la solution.
J'avais bien vérifié que mes ArrayController en mode Entity étaient bien liés à une entité correcte, mais je n'avais pas vu qu'un ArrayController en mode classe avait un binding sur le ManagedObjectContext.
Encore merci!