Changes between Version 7 and Version 8 of BluePrint/DatabaseMigration

Timestamp:

06/17/12 10:25:21 (13 years ago)

Author:

Fran Boon

Comment:

--

BluePrint/DatabaseMigration

@@ -18 +18 @@
 
 One way to achieve this would be to:
+* 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)
+{{{
+#!/bin/sh
+option1="myoption"
+export option1
+python web2py.py -S <liveapp> -M -R applications/liveapp/static/scripts/tool/migrationscript.py -A arg1 arg2
+}}}
 * create a new web2py application folder (e.g. {{{web2py/applications/test}}})
 * copy the old code/settings into this new folder
-* modifiy the settings in the new folder to change the DB name (e.g. 'sahanatest')
+* modifiy the settings in the new folder to change the DB name (e.g. '%supgradetest' % livedbname)
 * create the new DB in the OS
  * assume that localhost postgres sites can sudo postgres
@@ -29 +36 @@
  * rename them for MySQL/PostgreSQL
 * checkout the new code into the new application
+ * either break out to OS or use a Python wrapper:
+  * http://stackoverflow.com/questions/1456269/python-git-module-experiences
 * calculate the ability of the system to do an automatic migration
  * [http://web2py.com/books/default/chapter/29/6#Gotchas database-specific issues with Web2Py's automatic migration]
 * if OK, then do the migration & let the users test
+ * still provide a report on all schema changes for review, as this allows the testing to focus on these issues
 * if not OK, then build a migration script
 * if confident that the migration script is complete, then do the migration & let the users test