Re: Managing Files with CoreData
Re: Managing Files with CoreData
- Subject: Re: Managing Files with CoreData
- From: mmalc Crawford <email@hidden>
- Date: Sun, 18 Jul 2010 22:45:44 -0700
On Jul 18, 2010, at 1: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.
>
Per Keary's reply, the documentation makes it abundantly clear that it's not a beginner's tool. It comes with a number of prerequisites...
> It is extremely finicky and unforgiving.
>
... you have to use it correctly, yes...
> In fact, even with DTS support, I have never been
> able to get NSFetchedResultsController to work using a cache.
>
The standard Xcode Navigation-based application project template shows you how you can use a fetched results controller with a cache. What are you doing that doesn't match up with that? You haven't said in what way it's not working?
> 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.
>
You mean that there is no File entity in the managed object model?
Well, that would be a problem; if this is the case, it's not clear how you would expect this to work?
> 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?
>
What is the name of the entity, and what problem are you observing with the cache? You haven't said anything about how you're using the controller? Are you changing the predicate every time you use it, for example?
> 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?
>
The documentation for dealloc is quite explicit:
"You should typically not override this method—instead you should put “clean-up” code in prepareForDeletion or didTurnIntoFault."
<http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObject_Class/Reference/NSManagedObject.html#//apple_ref/occ/instm/NSManagedObject/dealloc>
> 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?)
>
The documentation addresses this issue directly:
<http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154-SW1>
and it's part of the introductory tutorial:
<http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/06_runClass.html#//apple_ref/doc/uid/TP40001800-CH234-TP9>
> Question 4: Is there any reason why you can't add additional methods (not
> ivars) to Managed object code-files?
>
Why would you think you cannot?
Again, this is part of the introductory tutorial.
<http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/06_runClass.html#//apple_ref/doc/uid/TP40001800-CH234-TP9>
and from <http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdManagedObjects.html#//apple_ref/doc/uid/TP40003397-SW1>:
"You might implement a custom class, for example, to provide custom accessor or validation methods, to use non-standard attributes, to specify dependent keys, to calculate derived values, or to implement any other custom logic."
> 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?
>
Fundamentally, this isn't a Core Data issue...
> 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.
>
... Core Data is an object graph management and persistence framework. Outside of the scope of object graph management and persistence, you treat managed objects pretty much just as you would any other. There isn't anything or there is very little in the Core Data documentation about interaction with sound generation, drawing, game playing logic, and so on: although you could use Core Data in a sound manipulation application, a drawing application, or in a game (amongst a myriad of other domains), the patterns and techniques you use are specific to those domains and in general not affected by the fact that you're using Core Data. If you manage file paths, the way you do so is just the same as you would were you not using Core Data. Modulo the fact that Core Data provides a useful method that's called when an object is about to be deleted, which means you can perhaps more readily tie the lifetime of the file to the real "lifetime" of a managed object, rather than having to invent your own pattern.
> 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.
>
From a quick look, it seems that it's a C++ framework, which typically doesn't have a good impedance match with Cocoa... Moreover, it seems concerned primarily with the persistence side of things rather than object graph management.
mmalc
_______________________________________________
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