|Version 4 (modified by Joe Tennies, 3 years ago) (diff)|
Schema Evolution Design
A way to migrate database changes as a project evolves.
Design: JoeTennies Development:
- Design drafted
- Design proposed
- Design approved
- Implementation drafted
- Implementation proposed <put ticket number here>
- Ticket approved
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.
- Warn user to backup database
- Make user accept warning before doing
- Store revision number of tables
- Store updates as python scripts
- Modify database schemas (Will require updates to database API)
- Add columns
- Default values - function to do this
- Remove columns
- Change table names
- Change column types
- Automatic int/float conversion
- Automatic string length conversion
- Change column/table attributes
- Add columns
- Allow personal patches against a database schema?
- This would allow an individual to store customizations but still be able to do schema migrations
- Detect bad migrations
- Detect that data may be lost
- Autodetection of changes
- This should be left for external tools like South or nashvegas to do
- Reverse migrations? (from version 6 to version 4)
Parameters: app - the app to be migrated as a string return_value - class that has a function to cancel the migration???
Sent just before starting running migrations for an app.
Parameters: app - the app to be migrated as a string
Sent just after migration successfully finishes for an app. Note that if the migrations fail in the middle of executing, this will not get called.