Using Core Data ManagedObjectIDs to uniquely name files
Using Core Data ManagedObjectIDs to uniquely name files
- Subject: Using Core Data ManagedObjectIDs to uniquely name files
- From: Ken Tabb <email@hidden>
- Date: Tue, 6 Apr 2010 12:27:18 +0100
Morning folks,
I have a Snow Leopard non-document based Core Data app (currently XML
based, but will be SQLite upon release). Supposing I have an entity
(Employee) that would like to store an auxiliary file (a tiff of their
mugshot), then as I see it I have the following options:
[1] Store the tiff within the Core Data store as a binary attribute.
Pros - presumably the easiest route.
Cons - it would generate much Time Machine activity I would assume, as
that single file will get big and be constantly updated every time
anything (images or any normal attribute) gets changed, so Time
Machine would basically be copying all the images each time when
perhaps it didn't need to (maybe the only difference since the last
backup is an Employee's name changed). Making for an unnecessarily
full Time Machine backup disk / terrible app performance if the user's
home directory isn't local.
[2] Store each mugshot as a separate file in a known folder (eg. a
subfolder of the app's Application Support folder, where the store is
also hanging out), and manually keep a tally of unique filenames
within the store / entity so that nothing clashes.
Pros - Less unnecessary backup activity / home directory accessing
etc. than the monolithic file in method [1].
Cons - My model doesn't have / need a unique ID as a modelled (by me)
attribute. Seems like a lot of unnecessary housekeeping work.
[3] Same as [2] but I could use the timestamp when the Employee record
was created as the filename
Pros - Less housekeeping
Cons - can I guarantee that, at some point, some bright spark won't re-
import the whole dataset on a fast machine and manage to get 2
different Employees created during the same slice of time (thus
sharing the same mugshot filename attribute, and overwriting each
other on the filesystem whenever either updates their pic)?
[4] Basically the same as [2] but using all or part of the Employee's
objectID as the filename, so that I can derive a built in unique
filename and don't have to do housekeeping. If I ensure I get a
permanent ID using the context's -obtainPermanentIDsForObjects:error:
method, and remembering that this isn't a document based app, so it's
happy assigning permanent IDs even on the first launch of the app,
then I get an objectID URI looking like:
x-coredata://3756AD1D-C658-409C-9EDD-E3EED0C898B1/Employee/p101
... and successive Employee objects differ only in that they end with
p102, p103 etc.
If it makes any difference, during testing I'm sticking with an XML
store, but for shipping it'll be an SQLite store. Also, it's only
Employee objects that will need to store any files, so I'm not worried
about the existence of Department/p101 objects etc. clashing.
My questions are:
[1] Presuming that my Employee objects all have permanent objectIDs,
can I rely upon using [[[[myEmployee] objectID] URIRepresentation]
lastPathComponent] as a unique filename for that object? i.e. so that
I end up with p101.tiff, p102.tiff images.
[2] Is an object's permanent ID truly permanent (for that saved
object, in that store, on that app, on that machine), or might it get
changed when an app's managed model gets modified (eg. when I start
making Company entities too, or if I add a 'shoesize' attribute to an
Employee) or during a future version of Core Data?
[3] Are the SQLite-based objectIDs similarly easy to get to the unique
bit (and similarly can I rely upon always being able to use them)?
Or is there a better way of doing what I'm trying to do? The docs seem
rather thin on the ground in terms of permitted (read-only) uses of
the objectID, besides testing for equality, and for permanence. As I
say, the app is working fine at the moment (on a development release
XML store), but I just want to check if I'm making safe assumptions as
it feels almost as dirty and sneaky as playing with private APIs, and
I'd rather not base a shipping app on something just because it
happens to work right now for me on my machine :)
As ever, thanks in advance for any help you can give,
Ken
- - - - - - - - - -
Dr. Ken Tabb
Mac & UNIX Developer - Health & Human Sciences
Machine Vision & Neural Network researcher - School of Computer Science
University of Hertfordshire, UK
_______________________________________________
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