Propriétés récupérées en tant que propriétés d'une sous-classe NSManagedObject

Question

J'ai une sous-classe de NSManagedObject (NSMO) appelée Team. L'équipe a une relation de un à plusieurs avec une autre sous-classe de NSMO appelée Contrat. Le contrat a un 1-à-1 avec le joueur (un autre NSMO). Je voudrais simplifier mon code qui utilise Team et pouvoir simplement faire référence à ses "joueurs". Les joueurs seront simplement un groupe de joueurs ayant un contrat avec une équipe donnée.

J'ai essayé de créer une propriété récupérée appelée lecteurs dans l'outil de modélisation de données de XCode avec peu de succès. J'ai essayé beaucoup d'approches différentes, mais celle qui a le plus de sens est de le nommer "players", d'avoir la destination en tant que Player et enfin d'avoir comme prédicat "contract.team.name == SELF".

Dans ma classe Team, j'ai une propriété de NSArray appelée players (avec les lecteurs @dynamic dans l'implémentation). Quand je NSLog (@ "% @", self.players), il se déconnecte ...

Relationship fault for (<NSFetchedPropertyDescription: 0x6d19cd0>), name players, isOptional 1, isTransient 1, entity Team, renamingIdentifier players, validation predicates (
), warnings (
), versionHashModifier (null), fetchRequest <NSFetchRequest: 0x6d1a080> (entity: Player; predicate: (contract.team.name == SELF); sortDescriptors: ((null)); type: NSManagedObjectResultType;) on 0x6d38550 

... ce qui en fait aucun sens pour moi. J'ai l'impression de faire tellement de choses que je ne sais même pas par où commencer.

Donc je suppose que mes questions sont 1) Quel type devrait cette propriété récupérée assumer dans ma sous-classe NSMO. (Je l'ai fait NSArray mais apparemment c'est une NSFetchedPropertyDescription) 2) Quel code puis-je utiliser pour obtenir un tableau ou définir?

Merci! Rob

Answer 1

Vous obtenez le retour normal pour une relation récupérée. Ce que vous avez est un défaut, c'est-à-dire le fantôme d'un objet. Les objets gérés réels ne sont pas chargés jusqu'à ce que vous essayiez d'accéder directement à l'un de leurs attributs. Les données de base utilisent des défauts dans les relations pour éviter d'avoir à charger un grand nombre d'objets dans la mémoire juste pour trouver une petite partie de données.

Supposons que vous ayez une relation avec 1 000 objets gérés de l'autre côté et que vous ayez besoin d'une valeur entière de l'un de ces objets gérés. Sans faille, les données de base devraient charger 1000 objets en mémoire juste pour trouver et récupérer 32 bits de données. En cas de défaut, Core Data connaît où la valeur entière est et peut aller chercher cet objet avec sa valeur unique.

Vous pouvez traiter une propriété récupérée comme une matrice. Prenons le cas de cette sous-classe simple objet géré dans lequel theFetchedProperty est une propriété tiré par les cheveux avec un prédicat de "TestEntity.order>5"

@interface TestEntityMO : NSManagedObject 
{} 
@property (nonatomic, retain) NSNumber * order; 
@property(nonatomic, retain) NSArray *theFetchedProperty; 

Mettre en place comme ceci:

TestEntityMO *testMO; 
for (int i=0; i<10; i++) { 
    testMO=[NSEntityDescription insertNewObjectForEntityForName:@"TestEntity" inManagedObjectContext:self.managedObjectContext]; 
    testMO.order=[NSNumber numberWithInt:i]; 
} 

Ensuite, connectez-vous le dernier objet TestEntityMO créé. La première fois que vous vous connectez la propriété, elle renvoie une erreur:

NSLog(@"testMO.theFetchedProperty == %@",testMO.theFetchedProperty); 

sorties

testMO.theFetchedProperty == Relationship fault for (<NSFetchedPropertyDescription: 0x3d19210>), //... rest removed for brevity 

...mais vous pouvez vous connecter le compte de la propriété tiré par les cheveux tout comme un tableau:

NSLog(@"[testMO.theFetchedProperty count] == %d",[testMO.theFetchedProperty count]); 

... Sorties:

[testMO.theFetchedProperty count] == 4 

Vous pouvez obtenir l'objet à un indice comme un tableau:

NSLog(@"[testMO.theFetchedProperty objectAtIndex:0] == %@",[testMO.theFetchedProperty objectAtIndex:0]); 

... sorties de la description d'un objet TestEntityMO (qui peut ou peut ne pas être la faute Dans ce cas, non.):

[testMO.theFetchedProperty objectAtIndex:0] == <TestEntityMO: 0x3d20a70> (entity: TestEntity; id: 0x3d20ab0 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A11> ; data: { 
    order = 9; 
    theFetchedProperty =  (
     0x3d20ab0 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A11>, 
     0x3d20a00 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A10>, 
     0x3d20880 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A8>, 
     0x3d20970 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A9> 
    ); 
}) 

la journalisation valeur d'un attribut d'un objet aléatoire:

NSLog(@"[[testMO.theFetchedProperty objectAtIndex:0] order] == %@",[[testMO.theFetchedProperty objectAtIndex:1] order]); 

... Sorties:

[[testMO.theFetchedProperty objectAtIndex:1] order] == 8 

Cependant, si vous vous connectez la propriété récupéré une seconde fois après vous déclenchez le chercher par le code au dessus de vous obtenez un objet réel:

NSLog(@"testMO.theFetchedProperty == %@",testMO.theFetchedProperty); 

... Sorties:

testMO.theFetchedProperty == Relationship objects for (
    <TestEntityMO: 0x3d20a70> ... ; 
data: { 
    order = 9; 
    theFetchedProperty =  (
     0x3d20ab0 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A11>, 
     0x3d20a00 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A10>, 
     0x3d20880 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A8>, 
     0x3d20970 <x-coredata:///TestEntity/t3A79EE49-39F4-4FCA-8E25-0C28B8E0E01A9> 
    ); 
}),... 

En résumé, vous pouvez:

1. Traiter les relations tout comme tirées par les cheveux NSArrays dans le code.
2. Comme pour tous les objets gérés, vous verrez souvent une erreur si vous vous connectez directement à l'objet.

Answer 2

Pouvez-vous simplement appeler [aTeam valueForKeyPath:@"contracts.player"]?