Core Data-Problem
Erik Meißner
ich melde mich mal mit einem Problem an Euch, vielleicht kann mir ja jemand einen Pointer in die richtige Richtung geben... :-)
Zur Zeit programmiere ich an einem kleinen Tool, das mir einen größeren Datensatz in Core Data aufbereiten soll inkl. Editor. Startpunkt ist das “Cocoa Application”-Template mit “Use Core Data” und “Create Document-Based Application” ausgewählt.
Die Applikation enthält ein sehr einfaches Managed Object Model und in dieses soll der größere Datensatz importiert werden. Das UI ist mit Bindings an das Core Data-Dokument angebunden. So weit, so gut, aber das UI hängt natürlich, aber das habe ich auch erwartet.
Um dieses Problem zu beheben wird eine NSOperation erzeugt, die den Import im Hintergrund durchführen soll. Die NSOperation hat ihren eigenen ManagedObjectContext, der in den ManagedObjectContext des Main-Threads gemerget werden muss, damit das UI weiterhin aktualisiert wird. Und hier beginnt das Problem: Es wird nicht gemerget, es wird eine Exception geworfen:
2011-11-14 22:12:59.950 CoreDataTest[21596:5d03] An uncaught exception was raised
2011-11-14 22:13:00.070 CoreDataTest[21596:5d03] This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.
[Switching to process 21596 thread 0×903]
2011-11-14 22:13:03.093 CoreDataTest[21596:5d03] * Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.’
terminate called after throwing an instance of ‘NSException’
warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn’t in the frame.
Ich gehe davon aus, dass ich einen PersistentStore dem PersistentStoreCoordinator hinzufügen muss, aber ich habe folgende Anforderungen:
• Ein neues Dokument hat keine Datei zugeordnet
• Ein neues Dokument ist nicht "Dirty”
• Während des Importvorgangs soll das UI regelmäßig über Bindings aktualisiert werden
• Nach dem Import ist das Dokument "Dirty", hat aber weiterhin keine Datei zugeordnet
• Nach der Auswahl von "Speichern..." kommt die Dateiauswahlbox und der Benutzer kann Dateinamen und Speicherort auswählen
• Nach dem Abspeichern des Dokuments an den Speicherort das Dokument ist wieder "Sauber"
Habt Ihr eine Idee, was das korrekte Vorgehen für solche Applikationen ist? Mit eine "Nicht Document-Based Application" ist es eigentlich auch kein Problem...
Viele Grüße,
Erik
Frank Illenberger
Eine weitere einfache Möglichkeit wäre, auf Bindings zu verzichten, dabei auf der Main-Queue zu bleiben und die Arbeit in kleinere Blöcke zu zerlegen, die man asynchron abarbeitet. Und nach größeren importierten Abschnitten löst man regelmäßig manuell einen Refresh der UI aus.
Gruß
Frank
> --
> Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe CocoaHeads Frankfurt beigetreten sind.
> Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an cocoaheads...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an cocoaheads-frank...@googlegroups.com.
> Besuchen Sie die Gruppe unter http://groups.google.com/group/cocoaheads-frankfurt?hl=de, um weitere Optionen zu erhalten.
>
in...@erik-meissner.de
oh, die Methode migratePersistentStore:toURL:options:withType:error: habe ich gar nicht so richtig in meinem Context wahrgenommen. Das sieht zumindest nach einer gangbaren Lösung aus:
- so lange ich noch keinen Dateipfad habe nehme ich einen NSInMemoryStoreType
- da nach eine Art "Save As..." bei dem ich den Pfad angebe und als Typ NSSQLiteStoreType
Alternativ könnte ich, wenn der Speicher nicht reichen würde, an einem temporären Pfad einen NSSQLiteStoreType-Store anlegen und den dann an die aktuelle Position migrieren.
Ich darf mir heute noch eine Schulung über ein (zumindest gefühlt) veraltetes PDM-System anhören und werde es danach noch ausprobieren (bin ja neugierig).
Vielen Dank und viele Grüße,
Erik
Frank Illenberger <illen...@mac.com> hat am 15. November 2011 um 08:57 geschrieben: