| | 1 | = Schema Evolution Design = |
| | 2 | |
| | 3 | == Introduction == |
| | 4 | |
| | 5 | A way to migrate database changes as a project evolves. |
| | 6 | |
| | 7 | == Participants == |
| | 8 | |
| | 9 | Design: JoeTennies |
| | 10 | Development: |
| | 11 | |
| | 12 | == Status == |
| | 13 | |
| | 14 | * ~~Process started~~ |
| | 15 | * Design drafted |
| | 16 | * Design proposed |
| | 17 | * Design approved |
| | 18 | * Implementation drafted |
| | 19 | * Implementation proposed <put ticket number here> |
| | 20 | * Ticket approved |
| | 21 | * Released |
| | 22 | |
| | 23 | == Objectives == |
| | 24 | |
| | 25 | Primary are required for first round of implementation. Secondary are things to be considered in the design but not required for first round of implementation. |
| | 26 | |
| | 27 | === Primary == |
| | 28 | |
| | 29 | * Store revision number of tables |
| | 30 | * Store updates as python scripts |
| | 31 | * Reverse migrations? (from version 6 to version 4) |
| | 32 | * Modify database schemas (Will require updates to database API) |
| | 33 | * Add columns |
| | 34 | * Remove columns |
| | 35 | * Change table names |
| | 36 | * Change column lengths |
| | 37 | * Change column/table attributes |
| | 38 | * Unique |
| | 39 | |
| | 40 | |
| | 41 | === Secondary == |
| | 42 | |
| | 43 | * Allow personal patches against a database schema? |
| | 44 | * This would allow an individual to store customizations but still be able to do schema migrations |
| | 45 | * Detect bad migrations |
| | 46 | * Detect that data may be lost |
| | 47 | |
| | 48 | == Non-Goals == |
| | 49 | |
| | 50 | * Autodetection of changes |
| | 51 | * This should be left for external tools like South or nashvegas to do |