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, 11 May 2005 11:21:05 -0700
On May 11, 2005, at 10:20 AM, Bruno Blondeau wrote:
All these solutions are real nightmares... I thought CoreData was
supposed to help developers make things easiers.
Data migration, in general, is very hard. I'm not sure why people
think it is any harder with Core Dat than it is with, say, a regular
object graph. Given the fetching tools, the pervasive use of key/
value coding, the presence of a real data model, and the ability to
implement full business logic, it should be considerably easier.
That has certainly been my experience with EOF vs. "raw" object graphs.
Model changes are very frequent in typical applications and they
should be handled automatically in simple cases (if an attribute is
added, add the column, and use the default value for example).
Well, this is what is done in the XML case, so I really don't
understand why it isn't the case with the SQL data store...
SQLite did not support ALTER TABLE until very, very recently. IIRC
3.1.3 -- the version that ships with Tiger -- has very limited ALTER
TABLE support, if any at all. So adding or removing a "column" (the
change may be more complicated) is not simply a matter of writing an
appropriate ALTER TABLE SQL statement.
Given that ALTER TABLE was slated to be added to SQLite prior to any
release of Core Data beyond 1.0 and the subtle nastiness implied by
altering database schemas based upon model changes, the decision was
made not to pursue trying to hand twiddle a solution that would
require copying the data to a new table, deleting the old table and
creating yet another table with the new schema, and then migrating
the data back.
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?
If, say, Stone Design creates a new version of the raw model for a
Create! document (I chose Create! because (a) the documents are
relatively complex object graphs, (b) Andrew is using Key/Value
Archiving -- the typical solution, and (c) long ago, I worked on the
project and am familiar with the object model), then Stone Design is
going to have to write all of the code to migrate the old document
format to the new document format. Currently, this is done via
keyed archivers and conditional, version based, unarchiving of old
object graphs in the -initWithCoder: methods (and via other hooks for
supporting such conversions).
The same holds true in the development process. If you refactor your
object model -- raw or Core Data -- during development, you are
either going to have to migrate your "development data" to the new
format in code or throw it away and start anew. Key Value Archiving
does nicely ignore keys that do not exist and the XML store offers
similar features, with some caveats that come from the presence and
use of a well specified object model.
---
In general, migrating data written by one model to a new model is a
very, very hard problem once you get beyond the simple addition/
removal of single attributes. As soon as the entity hierarchy or
relationships are involved, it is much more than a simple "this
attribute maps to that attribute" problem. Even with attribute
addition/removal, there may be any number of situations where
business logic would dictate that simply grabbing a default value is
inappropriate or that the object graph will not otherwise have to be
morphed as a part of the move.
Core Data v1.0 is not totally lacking in features that support the
migration effort. Grabbing the metadata from a store does not
require a model. Therefore, you can push whatever you need into the
metadata dictionary to identify the version # of the object model
contained within the store. From there, it is a matter of shipping
your old managed object model in the application wrapper, creating a
new Core Data "stack" against that model, traversing the object
graph, and migrating it to the new model. For some very simple
changes, you can migrate the store to XML and create a new stack with
the new model with a new store against that migrated XML store -- the
next save will "convert" the data to the new model.
The userInfo dictionary can also be used to annotate a model with
migration information, if desired. Given that the model can be
mutated prior to use, you can easily store the user info in a
separate property list (or whatever format you desire) and apply said
information to the model before using it with a store.
In any case, the Core Data teams is certainly well aware of the
issues surrounding model migration. If you have specific features
you would like to see or situations that you feel need to be
supported, please file enhancement requests via http://
bugreporter.apple.com/.
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