devol-migrates.txt

Начну с описания противоречий, которые вынуждают применять определённые решения.
Придуманная мной год назад структура файлов и каталогов не подходит.
http://docs.google.com/Doc?id=dfb6ztc2_87cmw6bpfx
Потому что хеши не решают проблемы, потому что не учитываются 
Но обо всём поподробнее:
R1 В разных базах данных поддерживается разный набор свойств.
E: В базе postgresql есть имя sequence, а в mysql его нет.
E: В базе sqlite нет reference, а posgresql и mysql есть.
=> хеши будут специфичные для базы данных
=> подписывать миграции хешами нельзя.
=> нужно минимизировать применение инкрементальных миграций, т.к. это может привести к накоплению ошибкок БД.
=> нужно отказаться от SQL-миграций в большинстве случаев.

R2 Разные состояния базы данных могут оказаться для текущей БД одинаковыми
=> хеши будут специфичные для базы данных.
=> хеши могут совпадать для разных версий.
=> нужно хранить в БД evid текущей миграции для каждого приложения (каждой таблицы?).

R3 Миграция таблицы с данными сложнее миграции таблицы без данных
=> при создании миграции нужно напомнить пользователю, что в таблице могут быть данные.

R4 Миграция может не удасться.
=> нужно обеспечить простоту и быстроту повтора процесса миграции.
=> миграции нужно разбить на всегда успешную стадию и "рисковую" стадию.
=> нужно применять локинг таблиц и стараться разбивать процесс на мелкие транзакции.
=> нужно иметь возможность возвратиться к прошлому состоянию и попробовать снова.

R5 Миграция может затронуть несколько приложений.
=> выбирается "главное" приложение, куда и записываются изменения

R6 Миграция может заключаться в переименовании какого-либо приложения.
=> имя приложения не должно храниться в миграциях этого приложения.
=> каждому приложению должен выделяться UUID для отслеживания таких ситуаций.

R7 Миграция может заключаться в переименовании какой-либо модели
=> должен быть способ указать, что произошло переименование
=> ?

R9 Миграция может заключаться в переименовании какого-либо поля
=> должен быть способ указать, что произошло переименование
=> ?

RX По крайней мере, некоторые миграции должны быть кодом на python
RX Информация о миграциях должна записываться в систему контроля версий
RX Желательно, чтобы миграции располагались по-порядку
RX Несколько пользователей могут порождать миграции одновременно на разных компьютерах.
=> Миграции хранятся в файлах
=> Расширение файлов миграций будет .py
=> Миграции должны отличаться датой и названием.
=> Предлагается такой формат для миграций: 20091002-2130-type-name.py

SX Для обеспечения разных задач требуется разный формат миграций
SX Задача трансформации данных
=> Ввести тип миграций "data"
SX Задача пользовательской корректировки структуры
E: Добавить колонку, переименовать колонку
=> Ввести тип миграций "user"
SX Задача фиксации схемы БД (snapshot)
=> Ввести тип миграций "snap"

RX Не все миграции могут применяться, должен быть способ не применять миграцию.
RX При записи противоречивых миграций желательно получить конфликт системы контроля версий
=%