dans une expression de propriété de données principale, apparemment J'aimerais utiliser la ou les valeurs de la propriété de l'objet source dans le prédicat d'une propriété récupérée. P> aucune idée de la manière de résoudre ce problème ? P> $ fetch_source code> résout à un identifiant d'objet em> au lieu de l'objet lui-même. Cela a provoqué une exception "La classe n'est pas codée à la valeur clé ...". Ce qui est vrai puisque c'est l'objet qui répond à cette clé. (lldb) expression (NSString*) [(id)0x10101b200 description]
(NSString *) $0 = 0x0000000108b03880 @"0x10101b200 <x-coredata://8F1FBB6B-505B-4169-A9D0-10D48CE5D4DC/YammerMessage/p101>"
(lldb) expression (Class) [(id)0x10101b200 class]
(Class) $2 = _NSObjectID_48_0
4 Réponses :
Vous pouvez définir le type de résultat d'un NSFetchRequest avec la méthode SETRESULTTYPE :, pour obtenir NSManageDObjects, vous devez la définir sur NSMANDAGEDOBITEDRESULTTYPE.
NSFetchRequest *fetchrequest = [[NSFetchRequest alloc] init]; [fetchRequest setResultType:NSManagedObjectResultType];
Sélection de la propriété récupérée dans l'éditeur de Coredata, je ne peux définir que le nom, la destination, les paires de prédicats et de la valeur clé du dictionnaire userinfo. Comment choisissez-vous le type de résultat? Merci.
J'ai ajouté une capture d'écran à ma réponse
Ceci a été corrigé dans une future version d'iOS (j'ai soumis un bogue.)
Pourriez-vous élaborer un peu? Est-ce un bug iOS confirmé?
Je (et d'autres personnes dans les forums des développeurs Apple) appartiennent au même problème dans iOS 7.1 - J'ai soumis un bogue # 16697979.
Est-ce un correctif de confirmation? BTW, c'est une application OS X.
Il n'est définitivement pas corrigé sur OS X ou iOS. Dupliquer ce radar: OPENRADAR.ME/16605433
@Quellish vient de trouver ce problème, lors de la conversion de mon application pour utiliser des contextes enfants et parents, par hasard, connaissez-vous une bonne solution de contournement? Merci pour cette liaison radar.
Vous avez absolument raison. $ Fetch_source se résout à NsmaniedObjecteDetid, donc quelque chose comme $ fetch_source.myproperty va jeter une exception (même si la documentation d'Apple utilise cette notation).
Je l'ai résolu en ajoutant la catégorie suivante à mon projet, ce qui attire l'appel et les transmet à la Objet réel: ps J'utilise MagicalRecord, d'où le raccourci defaultContext . Utilisez un MOC approprié dans votre code.
Cela ne fonctionnera que si vous avez un seul contexte, comme un enregistrement magique. Ne fonctionnera pas sur des applications plus complexes avec plusieurs piles de données de base et d'où plusieurs contextes peuvent être actifs. Outre un identifiant d'objet géré est généralement moins de contexte.
Tu as raison. Il s'agit d'une solution rapide, pas une solution universelle.
Je pense que le point de nsmanagedcontext Vous pouvez facilement le sélectionner par n'importe quel moyen soit magicalrecord ou en utilisant des méthodes normales.
Il semble que ce bogue ne soit pas encore corrigé dans iOS 11 et Xcode 9. J'abandonne enfin une propriété récupérée mais en utilisant une propriété calculée à la place. Ils utilisent le même sous-jacent Voici un exemple de code d'extraction: nsfetchrequest après tout.
Assurez-vous que vous pouvez accéder aux propriétés de votre $ Fetch_Source dans votre prédicat. Je suis certain que j'ai. Vérifiez Docs [ développeur.apple.com/library/mac/#documentation/cocoa/concepep Tual / ... . Pouvez-vous poster votre prédicat?
Je suis confronté au même problème et il semble être lié à la création de contextes à l'aide de l'API de Retikit. Si j'utilise la pile de Coredata ordinaire, tout fonctionne comme il se doit. Avez-vous trouvé une solution?