Schema Evolution Design

Introduction

A way to migrate database changes as a project evolves.

Participants

Design: JoeTennies Development:

Status

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

Objectives

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.

Primary

• 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

Secondary

• 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

Non-Goals

• Autodetection of changes
  • This should be left for external tools like South or nashvegas to do
• Reverse migrations? (from version 6 to version 4)

Code Design

Signals

pre_migration

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.

post migration

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.