Как обновить базу данных производства приложений TurboGears

Question

Как обновить базу данных производства приложений TurboGears

1

У меня есть производственная база данных postgres на производстве (которая содержит много данных). теперь мне нужно изменить модель tg-app, чтобы добавить пару новых таблиц в базу данных.

Как мне это сделать? Я использую sqlAlchemy.

Mohit Ranka 19 нояб. 2008, в 12:52

Источник

Теги:

database

python

postgresql

data-migration

turbogears

4 ответа

1

Я бы согласился в целом с John. Однопроходное SELECT и INSERTing не было бы практичным для большой базы данных, и настройка разностных или многопроходных дифференциальных SELECT/INSERT, вероятно, была бы более сложной и подверженной ошибкам.

Лично я использую SQLAlchemy как ORM в TurboGears. Чтобы выполнить миграцию схемы, я запускаю:

tg-admin sql status

Чтобы увидеть разницу между схемами live и development, затем вручную создайте сценарии DDL (и управления версиями), чтобы внести необходимые изменения.

Для тех, кто использует SQLAlchemy автономно (т.е. не под TurboGears), функциональность sql status довольно проста и может быть найдена здесь в источнике TG: http://svn.turbogears.org/branches/1.1/turbogears/command/sacommand.py (там версии для более старых версий Python/SA в ветке 1.0 тоже).

James Brady 23 дек. 2008, в 22:13

1

Самый простой способ - просто написать несколько сценариев обновления sql и использовать их для обновления базы данных. Очевидно, что подход довольно низкого уровня (как бы).

Если вы думаете, что будете делать это много и хотите придерживаться на Python, вы можете посмотреть sqlalchemy-migrate. В недавнем журнале Python была статья об этом.

John Montgomery 19 нояб. 2008, в 09:51

0

Если вы просто добавляете таблицы и не изменяете ни одну из таблиц, в которых есть существующие данные, вы можете просто добавить новые определения таблицы sqlAlchemy в model.py и запустить:

tg-admin sql create

Это не будет перезаписывать любые существующие таблицы.

Для миграции схемы вы можете взглянуть на http://code.google.com/p/sqlalchemy-migrate/, хотя я еще не использовал его сам.

Всегда делайте резервную копию производственной базы данных перед миграцией.

EoghanM 19 нояб. 2008, в 09:21

Ещё вопросы

S.Lott · Accepted Answer · 2008-11-19T10-44-00.000Z

Это всегда работает и требует мало размышлений - только терпение.

Сделайте резервную копию.
Собственно создайте резервную копию. Все пропускают шаг 1, думая, что у них есть резервная копия, но они никогда не смогут найти ее или работать с ней. Не доверяйте резервной копии, из которой невозможно восстановить.
Создайте новую схему базы данных.
Определите новую структуру с нуля в новой схеме. В идеале вы запустите DDL script, который будет строить новую схему. У вас нет script для построения схемы? Создайте его и установите его под контроль версии.

С помощью SA вы можете определить свои таблицы и построить свою схему для вас. Это идеально, поскольку у вас есть ваша схема под управлением версиями в Python.
Переместить данные.

а. Для таблиц, которые не меняют структуру, переместите данные из старой схемы в новую схему с помощью простых инструкций INSERT/SELECT.

б. Для таблиц, которые изменили структуру, разработайте сценарии INSERT/SELECT, чтобы перенести данные с старого на новый. Часто это может быть один оператор SQL для новой таблицы. В некоторых случаях это должен быть цикл Python с двумя открытыми соединениями.

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

У вас нет списка приложений? Сделай один. Серьезно - это важно.

Приложения имеют жестко кодированные конфигурации БД? Исправьте это тоже, пока вы на нем. Либо создайте общий файл конфигурации, либо используйте некоторую общую переменную среды или что-то, чтобы (а) обеспечить согласованность и (б) централизовать понятие "производство".

Вы можете делать такую процедуру каждый раз, когда выполняете крупную операцию. Он никогда не касается старой базы данных, кроме как для извлечения данных.

OP упоминает, что у него «много данных»: это может сделать цикл выбора / вставки нецелесообразным, если это означает часы или дни замедления, простоя или потери данных. Вместо этого, вы могли бы скопировать с мастера со старой конфигурацией на раб с новой?
Цикл выбора-вставки одного оператора SQL - самый быстрый способ перемещения данных. Любая операция с базой данных, требующая (а) перемещения данных и (б) абсолютной гарантии отсутствия простоев, должна выполняться таким образом. В противном случае просто добавьте таблицу.