Re: Modifying the data model
Re: Modifying the data model
- Subject: Re: Modifying the data model
- From: Chris Hanson <email@hidden>
- Date: Sun, 28 Aug 2005 15:04:09 -0700
On Aug 28, 2005, at 6:20 AM, Timothy Larkin wrote:
On the surface, I can understand the problem. But surely this
can't be the end of the story. If CoreData cannot cope with a
modification of the data model without invalidating all previous
data files, then it is a great step backwards from the old
NSArchiving classes.
When you set up a persistent store and save it using a particular
data model, that data model describes the data in the store. If you
then change the data model and try to use it with the data in that
store, it won't work, because the data model no longer describes the
data -- it describes data in some other format.
What you need to to is read your data using the old format and
transform it into whatever you want it to be now. This is actually
no different from NSArchiver and NSKeyedArchiver; you just have to do
it in a different way with those classes.
The problem is not a surface-level problem; it has a lot of depth to
it. Let's say you're creating an application that deals with
people. Your Person entity describes the information it tracks about
each person, including the name, height, gender, and hair color. Now
let's say in a subsequent revision that you want to add eye color as
Person attribute.
Everyone has an eye color so you want to make this a required
attribute. But nobody who is currently tracked has an eye color.
You *could* just say that it's not required at the data model level,
and instead just enforce the requirement in -validateForSave: (so any
changed objects will have to have an eye color assigned). You could
also decide on a default value. Maybe your application actually
tracks the DNA sequence of a person and can derive the eye color from
that.
My point is that even in this very simple case of adding an attribute
to an entity, transforming from one model to another ultimately
involves making decisions that are best left to your business logic.
Now imagine that you're not just adding an attribute, but *moving* an
attribute from one entity to another through a relationship. I.e.
you start with EntityA = { foo, bar } and you end with EntityAPrime =
{ foo, relToB }, EntityB = { bar, invRelToAPrime, baz }. Core Data
can't be made to understand, based on the limited structural
information specified in your model, the transformation that would
need to be applied to your data to interpret data using the first
model as if it were data using the second.
This is exactly the kind of thing business logic is good at.
-- Chris
_______________________________________________
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