Version 7 (modified by Joe Tennies <joe@…>, 8 years ago) (diff)


Schema Evolution Design


A way to migrate database changes as a project evolves. This is not being added to replace South, nashvegas, etc but for those tools to be based upon.


Design: JoeTennies Development:


  • Process started
  • Design drafted
  • Design proposed
  • Design approved
  • Implementation drafted
  • Implementation proposed <put ticket number here>
  • Ticket approved
  • Released


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
      • Unique
  • Reverse migrations? (from version 6 to version 4)


  • 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

Code Design




  • 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.

post migration


  • 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.


The storage will be a model with 2 fields:

  • app - the app to be migrated
  • modification - the modification installed
Back to Top