Core Data : Managed Object Context et héritage

Réponses

• Philippe49 Membre

  octobre 2009 22:38 modifié #2

  Voir du côté de NSFetchRequest
• nark Membre

  octobre 2009 22:38 modifié #3

  Merci encore Philippe.
  Je vais regarder, implémenter, tester, et je reviendrai surement.  :P
• yoann Membre

  octobre 2009 22:38 modifié #4

  Ce problème m'étonne un peut.
  
  J'utilise moi même ce système d'ancêtre commun pour gérer par exemple des UUID centralisé. Et pour autant je peut tout à  fait mettre un de ses enfants dans l'entity recherché par NSArrayController.
  
  Est-ce que tu peut nous faire un proto de ton problème histoire de voir ?
• ClicCool Membre

  octobre 2009 22:38 modifié #5

  dans 1255164167:

  
  Ce problème m'étonne un peu.../...
  

  
  
  Moi aussi,
  ça devrait marcher ainsi ...
  
  ... même si, à  mon sens, il peut aussi être intéressant de laisser l'entité mère comme "entité officielle" du ArrayControleur et, ponctuellement à  la demande, juste utiliser un FilterPredicate au grès des classes filles que l'on veut.
  
  
  

  <br />// soit TreeNodesACTRL un ArrayControleur gérant des entités &quot;TreeNode&quot;<br /><br />	NSPredicate *predicateur = [NSPredicate predicateWithFormat:&quot;className == &#092;&quot;RelationNode&#092;&quot;&quot;];<br /><br />	[TreeNodesACTRL setFilterPredicate: predicateur ];<br />	[TreeNodesACTRL rearrangeObjects];<br /><br />// TreeNodesACTRL ne contient maintenant plus que les RelationNodes<br />
  

  
  
  
• AliGator Membre, Modérateur

  octobre 2009 22:38 modifié #6

  ??? Un revenant ??? !!
  Heureux de te voir de passage parmi nous Hervé
• ClicCool Membre

  octobre 2009 22:38 modifié #7

  Merci Grand Maà®tre Ali,
  
  Pourfendeur des grincheux, de l'inexactitude et des posts trop courts !
  
  
  Tiens, il doit me rester une Cantillon, on va se l'ouvrir !
  A la tienne 
• muqaddar Administrateur

  octobre 2009 22:38 modifié #8

  Hervé ! Bienvenue revenant !
  J'espère que tu nous reviens pas que pour quelques jours hein ! Allé !
  
  Très content de te revoir en tout cas. A la tienne ! 
  
  ps : désolé de pourrir le post, mais là  c'est pour la bonne cause !
• ClicCool Membre

  octobre 2009 22:38 modifié #9

  Merci Alex 
  
  Tu sais, je sais jamais quand la "vraie vie" m'imposera un balck out !  :-\\
  
  J'ai perdu un certain nombre d'amis comme ça déjà  
  
  Mais bon, j'suis là   :brule:
  
  Mais t'as raison, pourrissons pas le sujet de Nark 
• Greensource Membre

  novembre 2009 22:38 modifié #10

  Je crois que mon problème ressemble un peu à  celui de nark.
  J'ai inscrit dans mon modèle Core Data deux entity, une (VLContact) hérite de NSManagedObject et contient juste un attribut name et eMail, deux NSString.
  Et j'ai une autre Entity, VLUser, qui elle hérite de VLContact, c'est bien inscrit dans le model. VLUser ajoute juste l'attribut password, toujours un NSString.
  
  Donc vu la hiérarchie je peut écrire:
  

  VLUser* userToSet = (VLUser*)[NSEntityDescription insertNewObjectForEntityForName:@&quot;VLUser&quot; <br />																&nbsp;  inManagedObjectContext:managedObjectContext];<br />		[userToSet setPassword:aPassword];<br />		[userToSet setName:aName];<br />		[userToSet setEMail:anEmail];
  

  
  Pas de souci, Xcode est d'accord. Mais quand je lance le bousin, j'ai une belle exception comme quoi l'instance de VLContact ne répond pas à  setName:
  

  -[VLContact setName:]: unrecognized selector sent to instance 0x3c0f2f0

  
  
  J'ai surement oublié quelques choses mais je ne vois pas quoi? Je vous joint mon model.

  3191_.png 49K

  3193_.png 51.8K
• yoann Membre

  novembre 2009 22:38 modifié #11

  Et avec un setValue:forKey: ça dit quoi ? :-)
• Greensource Membre

  novembre 2009 22:38 modifié #12

  Je sent que tu me charrie là ?
  Bon ça me marque que VLContact n'est pas KVC compliant mais pourtant je pensais que le .xcmodeldata le faisait directement?
  
  Je vois pas bien ce que je dois ajouter, des méthodes setValue:forKey: pour chaques attributes?
• yoann Membre

  novembre 2009 22:38 modifié #13

  T'es certain que ta classe mère VLContact est bien hérité de NSManagedObject ? C'est de la que viens la partie KVC
• Greensource Membre

  novembre 2009 22:38 modifié #14

  Ouais certain! D'après ça en tout cas:
  

  #import &lt;CoreData/CoreData.h&gt;<br />@interface VLContact :&nbsp; NSManagedObject&nbsp; <br />{<br />}<br />@property (nonatomic, retain) NSString * firstName;<br />@property (nonatomic, retain) NSString * lastName;<br />@property (nonatomic, retain) NSString * eMail;<br />@end<br />
  

  
  C'est embêtant en plus tout les tuto ou info que je trouve ne traite jamais de l'héritage...
• yoann Membre

  novembre 2009 22:38 modifié #15

  Ce qui est vachment plus embêtant c'est qu'on a pas a en parler normalement, il n'y a rien de particulier à  faire pour que ça marche ^^
  
  fait un clean all + build & analyse voir si t'as pas des messages d'erreur intéressant. Je vois pas trop là  comme ça
• ClicCool Membre

  novembre 2009 22:38 modifié #16

  -[VLContact setName:]: unrecognized selector sent to instance 0x3c0f2f0

  
  
  C'est normal que VLContact réponde pas à  setName.
  Il n'a pas de property name.
  
  

  dans 1258641418:

  
  Ouais certain! D'après ça en tout cas:
  

  #import &lt;CoreData/CoreData.h&gt;<br />@interface VLContact :&nbsp; NSManagedObject&nbsp; <br />{<br />}<br />@property (nonatomic, retain) NSString * firstName;<br />@property (nonatomic, retain) NSString * lastName;<br />@property (nonatomic, retain) NSString * eMail;<br />@end<br />
  

  
  C'est embêtant en plus tout les tuto ou info que je trouve ne traite jamais de l'héritage...
  

  
  
  Par contre setLastName ou setFirstName devraient fonctionner sans problème
• yoann Membre

  novembre 2009 22:38 modifié #17

  dans 1258665913:

  
  Par contre setLastName ou setFirstName devraient fonctionner sans problème
  

  
  
  Tout comme le setValue:forKey: non ?
• ClicCool Membre

  novembre 2009 22:38 modifié #18

  ;D
  
  Ceci dit le [tt]setValue: forKer:[/tt] reste intéressant pour une entité pour laquelle on a pas déclaré une autre classe que NSManagedObject.
  ça évite en effet d'entendre la complainte du compilo au fond des bois.
  Au runTime les accesseurs auront été générés par CoreData et ça marchera.
  Mais du coup il n'y aura aucun contrôle du compilo.
  Et la recommandation de la doc est plutôt de définir une catégorie de NSManagedObject dans laquelle on déclare les Properties du managedObject.
  

  Core Data Programming Guide a écrit:

  If you are not using a custom class, to suppress compiler warnings you can declare the properties in a category of NSManagedObject:

  
  
  
  Mais, dès lors qu'on défini et implémente une classe pour une entitée, il faut bien sur déclarer les Properties (ou déclarer et implémenter les accesseurs).
  

  Core Data Programming Guide: Dynamically-Generated Accessor Methods a écrit:

  For example, given an entity with an attribute firstName, Core Data automatically generates firstName, setFirstName:, primitiveFirstName, and setPrimitiveFirstName:. Core Data does this even for entities represented by NSManagedObject. To suppress compiler warnings when you invoke these methods, you should use the Objective-C 2.0 declared properties feature, as described in “Declaration.”
• Greensource Membre

  novembre 2009 22:38 modifié #19

  Nail y a eu juste un changement, j'ai renommer un attribut. Mais j'ai toujours le même souci. Pour rappel un VLUser est un VLContact avec un attribut password en plus.
  Donc j'écris:
  

  VLUser* userToSet = (VLUser*)[NSEntityDescription insertNewObjectForEntityForName:@&quot;VLUser&quot; <br />																&nbsp;  inManagedObjectContext:managedObjectContext];<br />		<br />		[userToSet setValue:anEmail forKey:@&quot;eMail&quot;];<br />		[userToSet setValue:aFirstName forKey:@&quot;firstName&quot;];<br />		[userToSet setValue:aLastName forKey:@&quot;lastName&quot;];<br />		[userToSet setValue:aPassword forKey:@&quot;password&quot;];
  

  
  et on me répond:
  

  [<VLContact 0x3c0f190> setValue:forUndefinedKey:]: the entity VLUser is not key value coding-compliant for the key "eMail".'

  
  
  J'ai fait un clean complet et rien n'y fait! Tu dit que ça devrais marcher yoann, tu as déjà  été dans le même cas?
• ClicCool Membre

  novembre 2009 novembre 2009 modifié #20

  A mon avis t'as du oublier un truc tout simple.
  
  

  dans 1258711172:

  .../... Pour rappel un VLUser est un VLContact avec un attribut password en plus.../...
  

  
  Par exemple:
  Il ne suffit pas que dans ton modèle VLUser déclare VLContact comme classe parente.
  Il faut aussi, bien sûr, que dans le header de VLUser tu le déclares comme sous classe de VLContact.

  #import &lt;CoreData/CoreData.h&gt;<br />@class VLContact;<br />@interface VLUser :  VLContact  <br />{<br />}<br />@property (nonatomic, retain) NSString * password;<br />.../...<br />@end
  
• Greensource Membre

  novembre 2009 22:38 modifié #21

  Oui j'ai vérifié ça et je l'ai bien fait:
  

  #import &quot;VLContact.h&quot;<br /><br /><br />@interface VLUser : VLContact {<br />	NSString* password;<br />}<br /><br />@property (nonatomic, retain) NSString * password;<br /><br />@end
  

  
  J'ai juste pas importe Core Data à  cet endroit, mais il l'est dans VLContact.h, ça suffit bien?
• ClicCool Membre

  novembre 2009 novembre 2009 modifié #22

  Ah ben, je me disais bien que t'avais juste oublié un truc simple 
  
  Non ça suffit pas pour un header, faut aussi y importer explicitement coredata.
  [EDIT] en fait pas si sûr mais pas le temps de vérifier, de toutes façons ça vaut le coup d'essayer, d'autant que je trouve l'usage de [tt]@class[/tt] plus propre que de compter sur des imports imbriqués qu'on fini par plus maitriser ...
  
  Et par contre si c'est pas indispensable (bien rare), mieux vaux simplement déclarer, avec [tt]@class [/tt], une classe qui est référencée dans le header d'une autre que d'importer son header ...
• Greensource Membre

  novembre 2009 22:38 modifié #23

  En effet c'est pas le temps que ça prend...mais ça ne marche toujours pas
  
  ps: Par contre quand je met
  

  @class VLContact;
  

  
  au lieu de
  

  #import "VLContact.h"
  

  
  
  Il est pas content, surement pcq pour l'heritage il a besoin de tout le header?
• ClicCool Membre

  novembre 2009 22:38 modifié #24

  dans 1258713484:

  .../...
  Il est pas content, surement pcq pour l'heritage il a besoin de tout le header?
  

  
  
  Oui t'as raison 
• ClicCool Membre

  novembre 2009 22:38 modifié #25

  dans 1258712094:

  
  

  #import &quot;VLContact.h&quot;<br /><br /><br />@interface VLUser : VLContact {<br />	NSString* password;<br />}<br /><br />@property (nonatomic, retain) NSString * password;<br /><br />@end
  

  
  

  
  
  Euh, pourquoi déclares-tu la variable password si elle figure bien dans le modèle ? @property suffit non ?
• ClicCool Membre

  novembre 2009 22:38 modifié #26

  Dans le genre truc simple, à  part oublier de déclarer la superclasse dans l'interface, y'a l'oubli inverse aussi ...
  
  T'as bien, dans le modèle, sélectionné la bonne classe parente dans le popUpMenu "Parent" de l'entité fille ?  ::)
• Greensource Membre

  novembre 2009 22:38 modifié #27

  :P énéfé je n'avais pas fait le lien, je croyais qu'écrire qui était la classe mère suffisait.
  Et bien merci pour tout, et pardons du dérangement, je range tout en partant...