Coredata Verlust, wenn das Lesen eine Eigenschaft

Ich habe folgenden Code in einer Schleife Iterieren über die verschiedene document Objekte:Coredata Verlust, wenn das Lesen eine Eigenschaft

NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; 
NSData* data = [document primitiveValueForKey:@"data"]; 
[document.managedObjectContext refreshObject:document mergeChanges:NO]; 
[pool release];

"Daten" Eigenschaft ist eine große BLOB (a 1MB-Bild). Und wie ich den Speicher mit dem Allocation Instrument Speicherverbrauch zunimmt. Ich kann nicht herausfinden, woher das Leck kommt und wie es entfernt wird.

Danke!

Quelle

2010-12-27 Kamchatka

ich nicht see * data * überall zugewiesen – Eiko

good point @Kamchatka, Sie erhalten den Wert für den Schlüssel 'data', setzen ihn aber auf nichts –

Ich möchte den Wert der Daten aus CoreData lesen und in eine Datei ablegen. Deshalb gebe ich ihm keinen Wert an. – Kamchatka

Ich schaffte es, das Problem zu lösen, indem Sie: [document.managedObjectContext processPendingChanges] kurz vor dem Ablassen des Pools. Allerdings verstehe ich nicht, welche ausstehenden Änderungen da wären? Könnte mich jemand darüber aufklären?

Quelle

2011-01-07 12:27:58 Kamchatka

Das liegt möglicherweise daran, dass Sie das Flag für mergeChanges setzen. Wenn Sie es auf NO setzen, wird ein neuer Fehler erstellt, der beim Zugriff ein neues Objekt erstellt. – LaN

Etwas ist mit dem Beispielcode falsch ist, haben Sie nach:

NSData *data = [document primitiveValueForKey:@"data"];

Als Daten, die derzeit im Rahmen Ihrer autoreleasepool ist es auch nicht freigegeben mit mit Ihrem autoreleasepool

Warum nicht zugeordnet sind Sie verwenden primitiveValueForKey und kein dynamischer Accessor?

Die dynamischen Accessoren sind viel effizient und ermöglichen Prüfung für Compile-Zeit.

Quelle

2010-12-27 17:50:20

Sie haben Recht, ich habe den Code geändert. Mein tatsächlicher Code übernimmt die Zuordnung zu "Daten "Ich bin nicht du Singe die dynamischen Accessoren, weil ich eine Migration mache. Die dynamischen Accessoren lesen die "Daten" aus der Datei, die ich während der Migration schreibe. Die Quelle von "Daten" ist jedoch während der Migration das Datenfeld in der alten CoreData Sqlite-Datenbank. – Kamchatka

Wie wäre es mit [pool drain] anstatt [pool release]?

Quelle

2011-01-04 14:28:11 Eimantas

Wie würde das helfen? Haben sie unter iOS kein ähnliches Verhalten? – Kamchatka

Sorry, verpasste den Teil über non-gc-Umgebung. Ignoriere meine Antwort (oder lehne sie ab). – Eimantas

Ihre Beobachtung, dass processPendingChanges das Problem zu lösen scheint, deutet darauf hin, dass der UndoManager für Ihren NSManagedObjectContext während des Imports alle Änderungen protokolliert, die Sie beim Massenimport vornehmen.

Was processPendingChanges tut (wie ich es verstehe) drückt Änderungen im ManagedObjectContext in den persistenten Speicher gespeichert.

Versuchen [[document managedObjectContext] setUndoManager:nil] (oder ein neues managedObjectContext für den Import erstellen und seine undoManager auf Null gesetzt, wenn Ihr document.managedObjectContext die ‚Haupt‘ managedObjectContext ist und Sie wollen nicht mehr rückgängig machen Registrierung auszuschalten.

Quelle

2011-01-09 00:39:56

Ich habe den UndoManager bereits auf Null gesetzt. Zusätzlich ist dies auf dem iPhone und ich denke, dass der UndoManager standardmäßig Null ist. – Kamchatka

Coredata Verlust, wenn das Lesen eine Eigenschaft

Antwort

Verwandte Themen