1 person found this helpful
I think it would be easier for you to decide whether to installing or update the database when the application starts up, rather than when it is installed.
On start-up, you just check wheter the database exists in the application-resource directory. If it doesn't, then you copy a template database file there. If it does exist, you check a version string you've conveniently stored in the database against the database version desired by your app, upgrading if necessary.
Thanks for your helpful response. I think you're right that the database management steps would happen on app startup after checking a version number stored in the DB.
What I'm wondering, however, is if there's a best practice for managing these incremental changes to the DB. My current direction is to create a class MigrationsManager, that creates an array of class Migration ( with a single migrate() function ) to manage each necessary and incremental change. Meanwhile, a "migrations" table has one column "version" with a UTC timestamp as an integer and is updated on each migration.
Rails does migrations with up() and down() functions on their base migration class, but the down() function isn't applicable since I can't imagine I would be rolling back earlier migrations on a user's DB.
In the end, I guess I'm just fishing of the best way of managing the different scenarios encountered when 3 years down the road you have an audience with all kinds of different versions of your app/db because of differences in how assiduous they were in updating to the most recent version.
For anybody interested I ended up writing "migration" classes that get added to each build. When the app starts up, it looks at the db version and then runs all migrations needed to get it up to the current version.