Re: Managing Files with CoreData
Re: Managing Files with CoreData
- Subject: Re: Managing Files with CoreData
- From: Gordon Apple <email@hidden>
- Date: Sun, 18 Jul 2010 21:19:17 -0500
- Thread-topic: Managing Files with CoreData
On 7/18/10 6:14 PM, "Keary Suska" <email@hidden> wrote:
> On Jul 18, 2010, at 2:20 PM, Gordon Apple wrote:
>
>> I have a series of questions about using CoreData (iPad). Although CoreData
>> is supposedly easy to use, I have found it anything but.
>
> I don't know where you got that--even the Core Data docs say it is an advanced
> API. I would say that once it is understood, it is certainly easier to
> implement than home-growing your own solution, but that's the only place it is
> truly easier and a time-saver, IMHO.
I have successfully used a database backend before, especially Bob
Krause's NeoAccess. IMHO, it beats the pants off of CoreData, and doesn't
have the impedance mismatch of a relational database, but is no longer
supported since he couldn't seem to find the right business model to make it
commercially successful.
>
>> 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.
>
>> Question 2: In the File class, what should I override to delete the actual
>> associated file when a file object is deleted from the database? (I'm
>> currently doing that separately when deleting the managed object.) Does
>> NSManagedObject's "dealloc" get called?
>
> -prepareForDeletion?
Sounds like a good place. Thanks.
>
>> Question 3: The main entity has several NSNumbers. Should I write
>> translators for each of these to make life easier? (Why wasn't this built
>> into CoreData in the first place?)
>
> Translators for what purpose? You haven't mentioned anything that would
> require converting NSNumbers.
For the purpose of accessing an actual int, float, bool, etc.
Currently, I've now got a bunch of numberWithBool, boolValue, etc. every
place where I used to have just a BOOL, etc.
>
>> Question 4: Is there any reason why you can't add additional methods (not
>> ivars) to Managed object code-files?
>
> No. I do it all the time.
Good. Some things are just not explained adequately in the docs.
>
>> Question 5: I'm currently formulating file URLs in a separate FileManager
>> object. Is there a better way for CoreData to manage file references? Full
>> URLs could be problematic, if later systems change anything. Maybe partial
>> URLs/paths relative to the application's documents folder?
>
> As far as choosing future-proof locations to store application data, using a
> relative path from a location for which there is an API call
> (NSHomeDirectory(), for instance), is probably your best bet. Although this is
> much less an issue on iPhone/iPad, where there are far fewer choices and users
> can't move stuff around.
>
>> 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.
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
Thanks for your response and comments.
_______________________________________________
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