Hi Gideon,
thanks for taking the time to reply. I see your point, if there were
more than 1 store being opened, but only 1 folder location for mugshot
files, then assuming that each 1st Employee would have the objectID:
x-coredata://.../Employee/p101
... then if I'm only using the p101 part, all my employees across
stores will start looking alike :)
As Sean just suggested, I was considering eventually making it all a
package (the non-document store and "mugshots" subdirectory all in 1
nice opaque file package) with the Employee deriving the location of
mugshot files relative to the location on disk of the store. So
hopefully that'd give each store it's own images folder, and the job's
a good 'un.
I think though, as you say, I'll use UUIDs just in case Core Data
evolves and (due to my own dependency on shifting sands) corrupts my
perceived data integrity. Or rather, highlights the lack of data
integrity caused by my assumptions :)
Thanks again,
Ken
On 6 Apr 2010, at 1:18, Gideon King wrote:
Hi Ken
If someone created another copy of your database, I imagine the last
path component could be duplicated, since it would not know about
the other copy and create the same primary key.
I believe that the URI is made up of the store id / entity /
reference object. With a document based application, the store id
changes when you do a save as, but I presume a non-document based
app would remain constant.
I entity related changes are identified in the metadata via a hash,
and I don't think they would affect the URI, but I haven't had cause
to check that.
Another option for naming your files may be based on a UUID you
store in your data, or perhaps something like a SHA1 hash of the
file, which would also let you know if the file had changed, if that
was of interest to you.
HTH
Gideon
On 06/04/2010, at 9:27 PM, Ken Tabb wrote:
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 (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
