Re: CoreData issue when updating a file format
Re: CoreData issue when updating a file format
- Subject: Re: CoreData issue when updating a file format
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 18 May 2005 01:07:36 -0700
On May 18, 2005, at 12:57 AM, Bruno Blondeau wrote:
On 11 mai 05, at 20:50, email@hidden wrote:
How is Apple expecting developers to easily use CoreData if model
migration isn't handled... well, this maybe won't be a problem for
v1 applications, but be prepared to hear a lot of complains from
developers new to CoreData, or even new to Cocoa, when they will
have to update the model of their applications...
Again; why is model migration with Core Data in the current release
any more or less difficult than migrating "raw" object models were in
Panther?
Well, with key/value archiving, if a key didn't exist, it was
easily possible to handle the case with a few lines of codes (for
example by choosing a default value)
For example, if I have
EVENTS
title
start date
end date
and try to add a description field, everything is very easy.
I understand model migration can be hard in many cases, but when
it's simply a matter of adding something simple to the model, I
think things should/could be easier.
File an enhancement request via http://bugreporter.apple.com/, please.
The situation you are describing is largely something that will only
happen within the development workflow -- changing schema for
production apps will generally imply a somewhat more complex
process. Given that, doing development work using the XML store
should work quite effectively. There will be a bit of overhead for
larger datasets, but "overhead" for the sake of "debuggability" is a
common tradeoff within any development environment.
A lot of effort -- many, many unit tests -- was expended upon
ensuring that the various store types behave identically in terms of
the API. The underlying performance characteristics and file I/O
patterns may be quite different, but that should not impact the
behavior of the API. If you do find a difference, file a bug.
One caveat: Obviously, the SQL store does incremental writes. The
rest of the stores perform atomic writes when updating the store.
As a result, the SQL store can actually encounter locking failures in
situations where the other stores will not. This does not change
the behavior of the API, but can change the error modes that may be
encountered while using said API (where the error modes are still
well defined).
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden