Updating a Database in a Deployed Mobile App
db.execute("REPLACE INTO daily_data (source,start,duration,flux_1000_300000,error_1000_300000,ul_1000_300000," +
"flux_300_1000,error_300_1000,ul_300_1000,flux_100_300000,error_100_300000,ul_100_300000,test_statistic)" +
"VALUES (1,56000,86400,10,1,0,9,2,0,1,0.5,0,32)");
db.execute("REPLACE INTO daily_data (source,start,duration,flux_1000_300000,error_1000_300000,ul_1000_300000," +
"flux_300_1000,error_300_1000,ul_300_1000,flux_100_300000,error_100_300000,ul_100_300000,test_statistic)" +
"VALUES (1,57000,86400,12,2,0,10,1.5,0,2,0.5,1,32)");
case 2:
db.execute("DELETE FROM " + c.T_DAILY);
db.execute("DELETE FROM " + c.T_WEEKLY);
Ti.App.Properties.setString('last_lc_data_update','0');
case 3:
db.execute(DATABASE_CREATE_GCN);
Ti.App.Properties.setString('last_GCNNotice_date', '0');
case 4:
...
...
default:
Ti.App.Properties.setInt('installed_db_version',c.current_version);
break;
}
db.close();
}
}
In version 1, I was using some dummy data that I was setting explicitly. In version 2, I had updated the code to get the data from a web service so I needed to remove all the old data and add a stored variable to track the date of the last data point. In version 3, I added a table to the database and an internal stored variable to track the date that data was last updated.
At the beginning of the code block, I check to see if the database is installed at all. If not I call a createDB() function. This function simply contains the code that creates the current version of the database schema. Another option would be to just set the installed_version to 0 and have a case 0: block that creates the original database schema that all the modifications are applied to but I believe it is faster and cleaner to just create the current schema rather than run through all the old ones applying one updated at a time. While probably not an issue if you only have a few changes, as the number of modifications grow, so does the time involved in the creation of the new database.
And there you have it. A simple straightforward way to make sure that your database updates go smoothly across updates of your application code.
One final note is that you don’t have to call this each time the app runs, but only the first time the database is used. Now I suspect in most cases, the database is used every time the application is run but if there are sections of your app that don’t use the database, this check can be delayed until first use of the database. This allows the app to load up a bit faster, although the difference may not be noticeable.
[1] There is a fourth possibility and that is that current_version is less than installed_version. But if you’re properly incrementing current_version then this should never happen unless you roll back a distributed version of your application. If you do that, all bets are off and you’ll need to find another way to handle the update. Of course this is only a worry if the older code can’t work with the newer schema.
Page 2 of 2 | Previous page