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 ==

• Store revision number of tables
• Store updates as python scripts
• Reverse migrations? (from version 6 to version 4)
• Modify database schemas (Will require updates to database API)
  • Add columns
  • Remove columns
  • Change table names
  • Change column lengths
  • 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