Changes between Version 7 and Version 8 of BluePrint/DatabaseMigration


Ignore:
Timestamp:
06/17/12 10:25:21 (9 years ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/DatabaseMigration

    v7 v8  
    1818
    1919One way to achieve this would be to:
     20* run the script in the context of the context of the current live app (allows pickup of some configuration automatically, with the rest being passed in as either os.environs or args)
     21{{{
     22#!/bin/sh
     23option1="myoption"
     24export option1
     25python web2py.py -S <liveapp> -M -R applications/liveapp/static/scripts/tool/migrationscript.py -A arg1 arg2
     26}}}
    2027* create a new web2py application folder (e.g. {{{web2py/applications/test}}})
    2128* copy the old code/settings into this new folder
    22 * modifiy the settings in the new folder to change the DB name (e.g. 'sahanatest')
     29* modifiy the settings in the new folder to change the DB name (e.g. '%supgradetest' % livedbname)
    2330* create the new DB in the OS
    2431 * assume that localhost postgres sites can sudo postgres
     
    2936 * rename them for MySQL/PostgreSQL
    3037* checkout the new code into the new application
     38 * either break out to OS or use a Python wrapper:
     39  * http://stackoverflow.com/questions/1456269/python-git-module-experiences
    3140* calculate the ability of the system to do an automatic migration
    3241 * [http://web2py.com/books/default/chapter/29/6#Gotchas database-specific issues with Web2Py's automatic migration]
    3342* if OK, then do the migration & let the users test
     43 * still provide a report on all schema changes for review, as this allows the testing to focus on these issues
    3444* if not OK, then build a migration script
    3545* if confident that the migration script is complete, then do the migration & let the users test