Re: Antw: Core Data PersistentStore woes with SQLite
Re: Antw: Core Data PersistentStore woes with SQLite
- Subject: Re: Antw: Core Data PersistentStore woes with SQLite
- From: Jim Correia <email@hidden>
- Date: Wed, 15 Nov 2006 09:23:58 -0500
On Nov 15, 2006, at 7:36 AM, Elise van Looij wrote:
But is it really such a problem to fix? I may be missing some Core
Data architecture ramifications, but isn't this simply a case of
"on change attribute is NSSQLiteStore then ALTER TABLE" (excuse the
Applescript-accent)?
This issue has been hashed over before. Check the archives.
<http://www.cocoabuilder.com/archive/message/cocoa/2005/5/11/135606>
for example.
Bill says that SQLite's ALTER TABLE support was insufficient.
After all, I was able to work around the problem by manually
altering the table in the sqlite store.
If you are going to do that in a production environment, I'd triple
check your work against the a store generated by CoreData from the
new model. For certain properties, there may be indices and/or
additional tables involved.
And Core Data is able to do the same thing by itself when using an
xml store.
There isn't any migration going on here. An XML store is an atomic
store, which means it is written in its entirety for each save. An
SQLite store is created and then updated, so the initial structure
dictates what can go into it. The only reason you are getting away
with this in the XML store is that NULL is an acceptable value for
the new attribute.
Dropping an attribute or adding an attribute where NULL (or the
model's default value) is an appropriate value is the simplest case
for data migration. After that, things get trickier.
Independent of the difficulty, or not, of the problem, CoreData
doesn't have any data migration build in on 10.4. So the choices
facing those of us shipping software (which uses the SQLite store) are
- never add a feature which requires a model change
- write some code to migrate the data over to the new store/model
You'll have to decide what is right for your situation and product(s).
Jim
_______________________________________________
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