Re: Importing to core data persistent document
Re: Importing to core data persistent document
- Subject: Re: Importing to core data persistent document
- From: Quincey Morris <email@hidden>
- Date: Wed, 4 Aug 2010 21:25:03 -0700
On Aug 4, 2010, at 19:48, Gideon King wrote:
> 1. User initiates import of file of type "fred"
> 2. I pick that up in -readFromURL:ofType:error:, and spawn a process which converts files of type "fred" to type "myfiletype", the native file type of the application. Let's say that it is stored in a file called /MyImports/file.mytype.
> 3. Still in -readFromURL:ofType:error:, I call super, telling it to load the converted file, and then call [self setFileURL:nil]; [self setFileType:@"myfiletype"];
>
> Result at this stage is that the file is open and displaying normally. Then the user saves the file:
>
> 1. saveToURL:... is called with the file name the user gave in the save panel.
> 2. writeToURL:... is called with the file name set to the new name, but in a temporary folder "(A Document Being Saved By myapplication)". This is the normal document saving process, and an empty file is created.
> 3. core data reads the empty file, and updates the cache nodes from the managed objects. All normal.
> 4. Now here is where the problem arises: core data now writes the data out to the file that was originally opened: /MyImports/file.mytype. The empty file has empty data written back to it.
> 5. The document architecture completes the save operation by moving the file (with no data in it) to the location the user said to save it to.
>
> Now if this was a normal "open and save as" operation, step 4 would have written the data to the file in the "(A Document Being Saved By myapplication)" folder, and it would have completed successfully.
>
> Therefore NSPersistentDocument knows it's a "Save As" operation, but the persistent store thinks it's a "Save" operation to the originally opened file which it remembers internally.
On Aug 4, 2010, at 21:09, Gideon King wrote:
> 1. It could come from a File/Open, or them opening that file from the Finder, or from a File/Import command (the import one just calls the document controller's openDocumentWithContentsOfURL:display:error anyway, so they all go through the same mechanism)
>
> 2. The file needing conversion does not require core data for the conversion. My file format is in core data.
>
> 3. Yes, the intention is so that it is treated as a new document. This works for the NSDocument side of things - I use the Save command, and it asks for a file name. It does not work for the persistent store side of things, because it tries to save back to the original file as well as writing a blank file to the new location. When you create a new document and save it for the first time in Core Data, it treats it exactly the same way as for a Save As (as far as I can tell), and that's the behavior I need in this situation, but I don't know how to achieve it because even if I tell Core Data there is no URL associated with the file (as would be the case for a new document, I assume), it still knows that it is not a new document.
OK, so I don't have any answers, but here are some questions:
1. Don't we know that NSPersistentDocument is (at least in some circumstances) unable to do a "real" Save As operation, and that it simulates Save As via a more fragile mechanism than NSDocument's? (My information, or mis-information, on this matter is from the Leopard era. Behavior could be different in Snow Leopard. Or I'm just wrong) It's possible this inability might be the limiting factor in what you're trying to do.
2. In the initial flow (the very first 1-3 steps above), can you find actual documentation that the API contract for NSDocument commits to supporting this behavior, namely translating an "Open" operation into a "New" operation? I'm not saying it doesn't, just that I've never seen documented the ability to set the file URL to nil as a way of getting this result.
3. If NSDocument supports that, is there any documentation evidence that NSPersistentDocument also supports it?
4. Don't we know that NSPersistentDocument's new-document handling is subtler or more complex than NSDocument's, especially in regard to when an actual file (persistent store) is created? I always believed -- perhaps wrongly -- that until an initial Save was performed, there was no actual persistent store, which meant that the entire object graph must be in memory. (Which, if true, means some difficulty for an application trying to create a very large untitled NSPersistentDocument, for example.) If I'm correct, then the scenario you're setting up is not anything that NSPersistentDocument would ever create on its own behalf.
TBH, when faced with the problem you're trying to solved, I've never dared do anything but stay away from the above kinds of shenanigans. I've always done the less elegant but more robust-seeming:
a. Implement File | Open as a custom action (or, sometimes, intercepting the NSDocumentController's document opening and doing something different, which I guess is what you'd need to do if you wanted File | Open to support both opening and importing, depending on what kind of file was chosen).
b. In the custom action, first asking for the file to import, *then asking for where to save the imported file*.
c. Doing the import, and creating the Core Data store in the specified location without the help of NSPersistentDocument.
d. Generating a NSPersistentDocument Open for the converted file.
IOW, with Core Data documents that are imported, they're never presented to the user as an untitled document. That's unfortunate from a consistency point of view (with NSDocument in general, I mean), but it's certainly reliable. My justification for that is whichever of my questions 1-4 explains why your approach doesn't work. :)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden