Changes between Version 13 and Version 14 of BluePrintDatabaseMigration

04/06/11 17:13:56 (12 years ago)
Pat Tressel



  • BluePrintDatabaseMigration

    v13 v14  
    7676=== Some suggested subsets for GSoC ===
     78This seems to fall naturally into three pieces:
     79 * Track schema changes revision by revision.
     80  * Compare schemas (e.g. those in Web2py *.table files) and report the differences.
     81  * Attempt to infer what happened (e.g. detect table name changes by matching columns in tables
     82    that were in the old schema but not the new to tables that appeared in the new schema).
     83  * Set this up to produce reports revision-by-revision (e.g. have the continuous integration build,
     84    which is triggered by commits to the Eden trunk, run a script).
     85 * Provide a UI that allows whoever made the schema change to tell how to convert the database.
     86   For instance, this could include allowing them to:
     87  * Match up renamed tables and columns.
     88  * Describe how to set a value for new unique columns in existing records.
     89  * Provide a template for subdividing records when tables are refactored (in straightforward cases).
     90  * Provide a script to do more complex conversions.
     91  * This subproject would only record the requested conversions, not apply them.
     92 * Design a process to convert a database at one revision into the form needed by a later revision.
     93  * Write a script that converts from revision N to N+1 given the conversion info from the above
     94    subprojects.
     95  * Write a script that backs up the database, gets the starting and ending revisions, and iterates
     96    over the conversions.
     97  * As an alternative, it might be possible to take the revision by revision conversions and
     98    generate an end-to-end conversion, then apply the end-to-end conversion to the database.
     99    This is likely not worth the effort -- its purpose would be speeding up the conversion, but
     100    it adds risk and is difficult. So long as the site upgrades fairly regularly, speed should
     101    not be an issue.
     102The first subproject is the most staightforward, and might not require the entire summer.
     103If so, one could get a start on the second subproject. It is possible to make these somewhat
     104independent by specifying what the output of the second subproject will be, so the third could
     105use that before the second was done.