Re: Using Core Data ManagedObjectIDs to uniquely name files
Re: Using Core Data ManagedObjectIDs to uniquely name files
- Subject: Re: Using Core Data ManagedObjectIDs to uniquely name files
- From: Gideon King <email@hidden>
- Date: Tue, 6 Apr 2010 22:18:44 +1000
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
>
_______________________________________________
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