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. > 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. > 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? > 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. > 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. > 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. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
