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

--

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.

Note: See TracWiki for help on using the wiki.
Back to Top