Changing table columns

3 views
Skip to first unread message

martypicco

unread,
Apr 16, 2009, 3:53:59 AM4/16/09
to sqlitepersistentobjects-user
Hi,

I added some columns to a table, and now things are going a bit
sideways.

New rows added during a given run of the app appear to be fine, but
when I restart the app, the data for the new columns are not correct
(they are zero).

How do I clean the database when I make changes to the schema?

Thanks,

Marty

Ian Terrell

unread,
Apr 16, 2009, 10:04:20 AM4/16/09
to sqlitepersiste...@googlegroups.com
I never had to do that for a live app, but for my app in development I would just delete the application from the device (or from the simulator, click and hold just like on the phone) and reinstall it.

martypicco

unread,
Apr 16, 2009, 12:02:49 PM4/16/09
to sqlitepersistentobjects-user
Thanks, Ian. That'll get me out of my immediate pickle.

It does raise the larger question of DB migration for live apps.

I presume that when an app is updated from the store, the DB persists
across the update, true?

I suppose that for production I'll have to implement a migration task
that's run at upgrade time to handle changes in the DB. Any pointers
you know of on best practice in this area?

Regards,

Marty

Ken

unread,
Apr 16, 2009, 12:19:05 PM4/16/09
to sqlitepersistentobjects-user
Marty,

In the simple case where you are storing your DB file in the documents
directory for your application, yes, the DB persists across updates.
I've done this with my app live in production, and it works fine.
However, if you do anything out of the ordinary, I would strongly
recommend you test thoroughly. Things that would be out of the
ordinary to me would be if you store your DB file outside your app's
document directory (such as in your resources folder in your app
bundle), or if you were to change your application identifier, or your
app's signing certificate. I don't know for sure that any of those
would cause problems, but I'd strongly recommend testing for anything
like that out of the ordinary.

As you suggest, for certain types of schema modifications, yes, a
migration task / script would be required. I've also done this with
success live in production. I store a schema version in a settings
table in the DB, and based on that schema version, determine if any
upgrade actions need to be performed. However, keep in mind that you
may not always need to explicitly perform migration actions, depending
on the nature of your schema change. If you've only added columns
(and you have added the corresponding properties to your objects for
those columns), then you would not need a migration script since SQLPO
would automatically add these columns when performing the table check
on next execution. There are other similar situations where a
migration would not be required. Again, thorough testing is highly
recommended.

Hope that helps.

martypicco

unread,
Apr 16, 2009, 12:55:22 PM4/16/09
to sqlitepersistentobjects-user
Thanks to you both. Everything is working and I have a good idea how
to move forward.

Marty
Reply all
Reply to author
Forward
0 new messages