Données de base ne retournant pas la propriété NSMutableArray

Question

Je commence à me sentir plutôt stupide - j'ai parcouru le site et ai trouvé quelques choses qui approchent de mon problème mais que je n'arrive pas à comprendre (aide M. Zarra, après en lisant votre livre, je me sentais plutôt bien avec Core Data mais maintenant je suis à bout de nerfs!). Malgré le conseil de l'expert, j'ai choisi de stocker un NSMutableArray en tant qu'attribut transformable dans mon entité de données de base. Le tableau lui-même est rempli avec des objets personnalisés et possède les méthodes requises encodeWithCoder: et initWithCoder :. J'ai ajouté NSLogs pour voir quand ils tirent.

Maintenant, en cours d'exécution pour la première fois, peuplant tout, etc., il est bien et je fais tout sauver la sortie (je peux voir dans le fichier xml que les choses se est codé en.)

Cependant, lors du redémarrage, En récupérant le NSManagedObject puis en essayant d'accéder à l'attribut transformable, je ne reçois rien de nouveau - malgré les instructions de log indiquant que le initWithCoder: s'est exécuté avec succès. C'est comme si le décodage se faisait dans le cadre de l'extraction de NSManagedObject mais que l'attribut lui-même n'était pas rempli (j'ai tout essayé, y compris setReturnsObjectsAsFaults: No). L'impression de la description de l'objet montre 'priceData - "(... pas nil ...)" donc je ne sais vraiment pas pourquoi il ne permet pas l'accès/retourne rien. Ce que j'essaye de faire est d'obtenir le mutableArray, vérifiez s'il contient un élément et si c'est le cas, remplacez-le par quelque chose d'autre. J'ai commencé ce matin et j'ai pensé que ce serait assez simple mais 7 heures plus tard je ne suis toujours nulle part. Le

Des idées du tout? J'apprécierais vraiment n'importe quelle aide/conseils/conseil dans cette matière.

[Question secondaire - pourquoi est-il idiot de mettre des données dans un tableau de données de base? J'ai affaire à de longues séries temporelles pour beaucoup, beaucoup de cas individuels et l'option d'extruder chaque point de données dans une entité semble créer une gigantesque table de points de données temporelles sur laquelle je suppose que la performance de récupération se dégraderait très rapidement. Ai-je tort]

Le code est donné ci-dessous:

NSManagedObjectContext *managedObjectContext = [[NSApp delegate] managedObjectContext]; 
//1. Retrieve the NSManagedObject with the price history from the MOC 
NSFetchRequest *request = [[[NSFetchRequest alloc] init] autorelease]; 
[request setIncludesSubentities:YES]; 
[request setIncludesPendingChanges:YES]; 
[request setIncludesPropertyValues:YES]; 
[request setReturnsObjectsAsFaults:NO]; 
NSEntityDescription *entity = 
[NSEntityDescription entityForName:@"stockPriceHistory" inManagedObjectContext:managedObjectContext]; 
[request setEntity:entity]; 
NSPredicate *predicate = 
[NSPredicate predicateWithFormat:@"stock == %@", [[self selectedObjects]objectAtIndex:0]]; 
[request setPredicate:predicate]; 
NSError *error; 
NSArray *array = [ managedObjectContext executeFetchRequest:request error:&error]; 

NSManagedObject *test = [array objectAtIndex:0]; 

NSLog([test description]); 
NSLog(@"%@",[[test priceData] description]); 

.. qui donne la sortie du journal suivant (les premières lignes sont les journaux montrant les horodateurs sur les objets du tableau se sont décodés à nouveau) :

2010-08-29 18: 48: 54,245 Project X [23047: a0f] 27.08.2010 13:00:00 0200

2010-08-29 18: 48: 54,246 Project X [23047: a0f] 2010-08-26 13:00:00 +0200

2010-08-29 18: 48: 54.250 Projet X [23047: a0f] 2010-08-25 13:00:00 +0200

2010-08-29 18: 48: 54.251 Projet X [23047: a0f] 2010-08-24 13:00:00 +0200

2010-08-29 18: 48: 54,252 projet X [23047: a0f] 2010-08-23 13:00:00 +0200

29/08/2010 18: 48: 54,253 Project X [23047: a0f] 2010-08-20 13:00:00 +0200

2010-08-29 18: 48: 54,253 Project X [23047: a0f ] 2010-08-19 13:00:00 +0200

2010-08 -29 18: 48: 54.255 Projet X [23047: a0f] 2010-08-18 13:00:00 +0200

2010-08-29 18:48:54.255 Projet X [23047: a0f] 2010-08-17 13:00:00 +0200

2010-08-29 18: 48: 54.256 Projet X [23047: a0f] 2010-08-16 13:00: 00 +0200

2010-08-29 18: 48: 54,256 projet X [23047: a0f] 2010-08-13 13:00:00 +0200

2010-08-29 18: 48: 54,257 Projet X [23047: a0f] 2010-08-12 13:00:00 +0200

2010-08-29 18: 48: 54.258 Projet X [23047: a0f] (entité: stockPriceHistory; id: 0x10043d950; data : { dataPointCount = 0; priceData = "(... non nul ..)"; stock = "0x100445040"; })

2010-08-29 18: 48: 54,260 Projet X [23047: a0f] ( ) (gdb)

Answer 1

Est-ce que vous substituez NSManagedObject pour cette classe? Si oui, avez-vous remplacé les accesseurs pour le tableau? Sa méthode awakeFromFetch est-elle invoquée? Où l'appel initWithCoder est-il effectué? Probablement devrait être dans awakeFromFetch. Vous pouvez avoir un attribut persistant 'codedArray' et un autre attribut non persistant 'array'. Dans awakeFromFetch, lisez l'attribut 'codedArray', décodez-le et définissez la propriété 'array' qui sera lue par le reste du code. Pourquoi ne mettez-vous qu'un tableau dans les données de base?

codedArray = [self valueForKey:@"codedArray"]; 
// decode array... 
[self setPrimitiveValue:decodedArray forKey:@"array"]; 

Euh, ouais, cela semble étrange. Si vous utilisez un codeur, vous pouvez simplement écrire dans un fichier plat. Puisque vous émettez chaque objet comme sa propre ligne, vous perdez les avantages d'une base de données SQL; vous devez lire tout le tableau en mémoire avant de faire des recherches dessus.