Schema Evolution Design

Introduction

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.

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

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

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.

Storage

The storage will be a model with 2 fields:

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