3 Replies Latest reply on Dec 21, 2009 10:20 AM by DMcQ

    Custom installer and database migrations

    DMcQ Level 1

      Has anybody blogged or have info on the process of creating custom installers for AIR? I mean complete custom installers not just a silent install of the runtime and then the AIR installer?

       

      I want to be able to install my AIR application's sqlite database on a fresh install, but leave the current database and update it through ActionScript if the install is replacing an earlier version of my app. My feeling is that, in addition to copying the basic files from the project directory, the customer installer just needs to remember to rename the MyApp-config.xml and place it in META-INF/AIR/application

       

      Any ideas about a pattern for approaching DB migrations would be most appreciated! I like how rails migrations work, and am thinking to try to create something similar internally within my app to manage the sequence of database changes that would be needed between the user's current version of our app and the new one they're installing.

       

      I think an upcoming incremental release of AIR will have some installer changes...is that right?

       

      Thanks for any help or ideas!

       

      - Daniel McQuillen

      McQuillen Interactive

        • 1. Re: Custom installer and database migrations
          Joe ... Ward Level 4

          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.

          1 person found this helpful
          • 2. Re: Custom installer and database migrations
            DMcQ Level 1

            Joe,

             

            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.

             

            - Daniel

            • 3. Re: Custom installer and database migrations
              DMcQ Level 1

              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.