NSFetchedResultsController et tables utilisant des relations

Comme un exemple simple, disons que j'ai 2 entités avec une relation plusieurs à plusieurs. La première entité s'appelle "Projets" et la seconde "Employés". L'entité de projet peut avoir 1 ou plusieurs employés et les employés peuvent être sur un ou plusieurs projets.

Encore une fois, pour des raisons de simplicité, Project a un atsortingbut appelé projectName et une relation à plusieurs avec Employee appelée withEmployees. Réciproquement, Employee a employeeName et a à plusieurs relations avec des projets appelés myProjects.

Utilisation de NSFetchedResultsController Je veux une table qui aura projectName comme nom de section et employeeName pour les lignes. En utilisant Project comme entité récupérée, je peux facilement get chaque projet et créer le nom de section approprié. Toutefois, le problème survient lors du calcul de numberOfRowsInSection. À mesure que les résultats récupérés récupéraient un logging pour le projet, numberofrows voyait une seule entité, car il ne s'intéresse pas au NSSet trouvé dans la relation .withEmployees. Cela signifie qu'un seul employé sera produit plutôt que le nombre du nombre dans la relation NSSet.

Comment surmonter ce problème pour utiliser une relation à plusieurs dans une table?

Merci.

Voici le code pour le fetchedcontroller:

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"Projects" inManagedObjectContext:self.managedObjectContext]; [fetchRequest setEntity:entity]; NSSortDescriptor *firstSort = [[NSSortDescriptor alloc] initWithKey:@"projectName" ascending:NO]; NSArray *sortDescriptors = @[firstSort]; [fetchRequest setSortDescriptors:sortDescriptors]; _fetchedController = [[NSFetchedResultsController alloc]initWithFetchRequest:fetchRequest managedObjectContext:self.managedObjectContext sectionNameKeyPath:@"projectName" cacheName:nil];

J'ai finalement trouvé la réponse. Les relations d'entité que j'avais étaient bien comme décrit ci-dessus. Le problème était à nouveau d'get le nombre correct de lignes renvoyées via la relation à plusieurs. J'ai résolu cela de la manière suivante:

 - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { Projects *project = [self.fetchedController objectAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:section]]; return [project.withEmployees count]; }

Avec ce qui précède, j'ai utilisé la section appropriée et puisque je sais qu'il y a toujours une ligne qui contient un set de taille inconnue, j'ai créé un path d'index qui regardait le seul et unique logging d'en-tête (le projet) pour chaque section. J'ai alors juste regardé dans le NSSet qui compose la relation et returnne simplement le count de cela. Maintenant, nous obtenons le nombre correct de lignes par section.

Quant aux cellules elles-mêmes:

 Projects *project = [self.fetchedController objectAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:atIndex.section]]; UITableViewCell *cell = [self.tableView dequeueReusableCellWithIdentifier:@"Cell" forIndexPath:atIndex]; NSArray *empArray = [project.withEmployees allObjects]; Employee *employee = [empArray objectAtIndex:atIndex.row]; cell.textLabel.text = employee.firstName; }

La key ici était d'get l'logging d'une section, puis de retirer toutes datatables qui composent la relation à plusieurs. Encore une fois j'ai besoin de créer un path d'index afin d'get seulement l'logging parent. Maintenant, en utilisant les lignes, je peux parcourir le tableau pour get chaque élément.

Que diriez-vous quelque chose comme

 - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { id<NSFetchedResultsSectionInfo> sectionInfo = [self.fetchedResultsController sections][section]; return [sectionInfo numberOfObjects]; }

Cela suppose que vous avez passé la sectionNameKeyPath: correcte sectionNameKeyPath: dans le contrôle de résultats récupérés -initWithFetchRequest:managedObjectContext:sectionNameKeypath:cacheName: call.

Remarque: les noms de relations suivent généralement les mêmes règles de dénomination que les propriétés ou les attributes. Au lieu de myProjects et withEmployees , utilisez des projects et des employees . Il fait mieux lire votre code: fred.projects au lieu de fred.myProjects , fred.projects au lieu de fred.myProjects .

Je ne peux pas encore commenter pour vous requestr ceci comme une réponse et un ajout possible au code ci-dessus:

J'ai réussi à récupérer l'entité de la relation dans un NSSet et l'afficher dans la tableview.

Cependant, j'essaie maintenant d'implémenter slide-to-delete à cette tableview et mon NSFRC ne peut pas save la suppression de l'object dans le tableau de la relation.

Dans cet exemple, cela signifierait: Je peux supprimer un object Project, mais si je supprime un object Employee, il se bloque car il enregistre (0,0) lignes ajoutées / supprimées.

Je le récupère de la même manière et ensuite supprime cet object:

 NSArray *empArray = [project.withEmployees allObjects]; Employee *employee = [empArray objectAtIndex:atIndex.row]; [context deleteObject:employee];

Avez-vous un travail autour par hasard?

Je n'ai actuellement aucun prédicat dans mon NSFRC pourrait-il changer les choses si elle a vérifié le project.employee à quelque chose? Ou devrais-je travailler avec deux NSFRC, un qui charge des projets et définit des sections, et un qui charge des employés et charge des lignes? Je pense qu'ils pourraient encore interférer lors de la détection d'un object supprimé.