| | 78 | This 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. |
| | 102 | The first subproject is the most staightforward, and might not require the entire summer. |
| | 103 | If so, one could get a start on the second subproject. It is possible to make these somewhat |
| | 104 | independent by specifying what the output of the second subproject will be, so the third could |
| | 105 | use that before the second was done. |
| | 106 | |
