On May 7, 2009, at 7:02 AM, I. Savant wrote:
On Wed, May 6, 2009 at 6:36 PM, Melissa J. Turner
<mjtur...@apple.com> wrote:
Context is important. Also future-proofing.
If your app was originally written against v1 CoreData (Tiger),
you need to
update the app to be wise enough to check the store's metadata and
run away,
run away from any store containing unexpected values (ie version hash
information). v1 CoreData always assumes that it can open a store
it was
told to open until later evidence proves otherwise; later versions of
CoreData realized that was perhaps an unwise decision, and added
the current
versioning and migration infrastructure. Due to binary
compatibility issues,
applications compiled on Tiger will continue to exhibit the old
behavior.
There's a general discussion of migration under 10.4 at
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdZ104Versioning.html#//apple_ref/doc/uid/TP40002989
Thanks, but I think I should clarify things a bit more succinctly:
1 - Version 1 of the app and data model were *started* on Tiger (I
created the project and worked on it under 10.4 for awhile).
2 - Later, when Leopard was released, I began linking against the 10.5
SDK and making use of some Leopard hotness.
3 - Version 1 of the app (and data model) was released as full-on
10.5-compiled and is 10.5-required (ie, has not been run on Tiger by
any users).
4 - Version 2 of the app and data model have a working automatic
migration for the very first change - the simple addition of a float
attribute to a single entity.
The problem is that version 1 of the app will open version 2 data
files without complaint. This is unexpected and - I dare say - wrong.
Unless you are specifying NSIgnorePersistentStoreVersioningOption as
an option to addPersistentStoreWithType:..., if there are any changes
to your data model that would result in changes to the data that is
persisted (adding/removing transients, validation rules, etc don't
count because it doesn't change the data stored externally), your
version hashes should be different between a version 1 data model and
a version 2 data store file, and that should result in a
NSPersistentStoreIncompatibleVersionHashError (134100).
A question: Could my having created the project under Tiger, then
later linking against 10.5 have caused this problem? In other words,
is the 10.4 version of the xcdatamodel still 10.4-limited when
compiled by momc, even when targeting 10.5?
No, unless you're project was configured with a 10.4 deployment target
(check your project and target build settings)
In any case, sorry for the previous wordy-confusion. That'll teach
me to wax poetic in my posts. ;-)
--
I.S.
_______________________________________________
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/aswift%40apple.com
This email sent to asw...@apple.com
_______________________________________________
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
