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: T Reaves <email@hidden>
- Date: Sun, 8 May 2005 11:41:26 -0400
This doesn't so much look tedious & non-trivial as it does a
nightmare! A big problem with data persistence shemas where no
thought is given to this type of issue is that data models get stale,
and application suffer. I've used several applications - one I'm
using now is less than a year old - where the functionality of the
application is severely constrained simply because the vendor would
find it too costly to migrate the data model, and breaking backwards
compatibility is out of the question.
It's too bad Apple didn't learn a thing or two from the Object
Database vendors about schema management. But there again, Apple
choose not to persist objects, but an objects data as basically a
map. With my favorite OODBMS when you mark an object as persistent
capable, the datastore saves the class definition as metadata. Any
instance of that object that gets persisted has a versionId
associated with it. When you reference an object, the bdms knows how
to interpret the bits based on the version of the class.
As for schema migration, it's handled very elegantly; the
default behavior when you reference an object that was persisted
under an old version ID was to add any new attributes, and drop any
that were removed. For base data types, the default value could be
provided, or nil was used. For associations, they were set to nil as
well.
For more complex transforms, say were you add a category type
object, and want existing objects to have category references added
and linked to instantiated categories, it was as simple as writing a
short script that was little more than an OQL script.
Even with large object graphs, I don't recall ever running into
a situation where it was difficult to do this.
I wonder if some type of similar semantics could be wrapped
around CoreData?
On May 6, 2005, at 10:52 PM, mmalcolm crawford wrote:
On May 6, 2005, at 1:07 PM, Jim Correia wrote:
On May 6, 2005, at 1:12 PM, mmalcolm crawford wrote:
On May 6, 2005, at 8:27 AM, Bruno Blondeau wrote:
I'm trying to open a CoreData/SQLite document which was saved
with a v1 model. I'm getting an error, while it is working fine
with the XML data store (which automatically adds the needed
columns for the v2 model).
File formats are not backwards compatible. If you change the
schema (model), you cannot read old files.
Is there a capsule summary of how this situation should be handled?
I hope Bill and Ben will forgive me forwarding these recent
suggestions:
(1) Put a version number in the metadata of your stores. (Of
course, the lack of a version number key being present is
indicative of version 1. :)
(2) When opening the store, first grab the metadata and check the
version #. You don't need a model (or even the type of the store)
to grab the metadata.
- obviously, if the version # is the latest and greatest, open
the store and run with it.
(3) If the version # is a previous version, then:
- grab the previous model
- initialize a Core Data stack with said model and store
- grab the latest and greatest model
- initialize a Core Data stack with the latest and greatest
model and a new store
- fetch the objects out of the old store and populate the new
store, mapping in between
It helps if the old model is modified-- this can be done in memory
before the model is used, if you want-- such that it doesn't use
any custom classes; simply loads all of the data as instances of
NSManagedObject.
The end result of this is that it is a KVC mapping problem.
"Instances of this entity become that entity. Attributes of this
name become that name. Members of this relationship are added to
that relationship. These new attributes are defaulted to these
values. Etc."
[...]
How you traverse the model is entirely up to you. When doing this
kind of object graph conversion, I typically do a traversal like:
- convert across all entities that are relatively standalone (i.e.
things that are more or less select lists like categories or
priorities or other items that typically show up in popups in the UI)
- create a old-global-id <-> new-global-id map as they are converted
- traverse the collection of "root" entities one by one, making new
instances in the new model, converting as needed.
... etc ...
Non-trivial, yes. Tedious, yes. But migrating data models is
typically hard.
--snip--
_______________________________________________
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