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: Bruno Blondeau <email@hidden>
- Date: Wed, 18 May 2005 14:49:08 +0200
On 18 mai 05, at 10:07, Bill Bumgarner wrote:
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.
[...]
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 problem I'm currently facing is that I'm storing document-specific
preferences (window position,...) in different fields of a singleton
object. Each time I'm adding a new preference, there is a trivial model
change. Using XML, everything was going smoothly during early
development. Now that I tried SQL, this isn't working. I think I'm
going to change the way I'm handling this, even if my previous solution
was very convenient when mixed with cocoa bindings. I will also have to
try to plan well in advance everything that is going to be needed in
future versions for the model side.
Bruno
_______________________________________________
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