Re: Managing Files with CoreData
Re: Managing Files with CoreData
- Subject: Re: Managing Files with CoreData
- From: Keary Suska <email@hidden>
- Date: Mon, 19 Jul 2010 07:27:00 -0600
On Jul 18, 2010, at 8:19 PM, Gordon Apple wrote:
>>> My main entity has three references (one-to-one and one-to-many) to
>>> identical entities defined as class "File" (a managed object). File is not
>>> defined in the graphical model and is the only class (for the referenced
>>> entities) defined in the code. File has a back reference, and two
>>> attributes, a user-assigned name and a code-assigned uniqueID integer, the
>>> latter of which forms the main part of the actual (internal) file name when
>>> file access is required. Actual files are stored in their respective
>>> subfolders of the documents folder for each defined File entity.
>>>
>>> Question 1: The FRC is for the main entity and sorts on the main entity's
>>> own name attribute. Is there anything is what I described above which could
>>> be interfering with using an FRC cache?
>>
>> I wouldn't assume so, but you haven't told us what "doesn't work" means.
>
> Here's the story. When the program is first launched, a folder of text
> files is read and and is used to pre-populate the database. This appears to
> work. However, even after saving and performFetch, the FRC will not get
> section info when going to a tab view containing a tableView. If I quit the
> app and relaunch, the table will populate correctly using the FRC. This is
> not a good initial experience for the user when first launching the program.
We would need to see code to make any useful recommendations. If you are saying that the exact same code functions correctly when *not* using a cache, but incorrectly when using a cache, I would suspect a bug of some sort. But then, the bug could be in your code...
>>> Comment: I have yet to see any sample code or writeups on using CoreData to
>>> manage files, which seems like something that should be in common usage.
>>
>> Why? Core Data is about object graph management (and its persistence). It
>> isn't about file system management. There are other classes for that.
>
> Well, it is not enough to define something in isolation. Many systems,
> like browsers, are based on individual file storage. If there is a common
> standard practice for handling file references in CoreData, I would prefer
> to use it.
Originally I was answering the wrong question. The right answer would be that there is almost nothing particular to persisting file references in Core Data vs any other approach. But I would also add that I bemoan the lack of examples for complex and advanced uses of Cocoa classes--it seems that examples deal primarily with common and simple cases.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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