Изменение таблиц базы данных в Django

Question

Я подумываю об использовании Django для проекта, который я запускаю (к вашему сведению, игра на основе браузера), и одна из функций, которая мне больше всего нравится, - это использование syncdb для автоматического создания таблиц базы данных на основе Модели Django, которые я определяю (особенность, которую я не могу найти ни в одной другой среде). Я уже думал, что это слишком хорошо, чтобы быть правдой, когда я увидел это в документации :

Syncdb не изменит существующие таблицы

syncdb будет создавать таблицы только для моделей, которые еще не установлены. Он никогда не будет выдавать операторы ALTER TABLE, соответствующие изменениям, внесенным в класс модели после установки. Изменения в модельных классах и схемах баз данных часто включают некоторую двусмысленность, и в этих случаях Django должен был бы угадать, какие именно изменения следует внести. Существует риск того, что важные данные будут потеряны в процессе.

Если вы внесли изменения в модель и хотите изменить таблицы базы данных, чтобы соответствовать, используйте команду sql, чтобы отобразить новую структуру SQL и сравнить ее с существующей схемой таблицы, чтобы отработать изменения.

Кажется, что изменение существующих таблиц должно быть сделано "вручную".

То, что я хотел бы знать, - лучший способ сделать это. На ум приходят два решения:

• Как следует из документации, внести изменения вручную в БД;
• Сделайте резервную копию базы данных, сотрите ее, снова создайте таблицы (с помощью syncdb, так как теперь они создают таблицы с нуля) и импортируйте резервные копии данных (это может занять слишком много времени, если база данных большая)

Есть идеи?

Answer 1

Внесение изменений в SQL и дамп / перезагрузка - оба варианта, но вы также можете проверить некоторые пакеты эволюции схемы для Django. Наиболее зрелые варианты: django-evolution и South .

РЕДАКТИРОВАТЬ : И эй, вот идет dmigrations .

ОБНОВЛЕНИЕ : С тех пор, как этот ответ был изначально написан, django-evolution и dmigrations прекратили активное развитие, а South стал де-факто стандарт для миграции схемы в Django. Части Юга могут даже быть интегрированы в Django в следующем выпуске или двух.

ОБНОВЛЕНИЕ : Фреймворк схемы миграции, основанный на Юге (автор Эндрю Годвин, автор Юга), включен в Django 1.7 +.

Answer 2

Как отмечалось в других ответах на ту же тему, обязательно посмотрите Панель эволюции схемы DjangoCon 2008 на YouTube.

Также два новых проекта на карте: Простые миграции и Миграционные .

Answer 3

Один хороший способ сделать это - это светильники, особенно приспособления initial_data.

Фиксатор - это набор файлов, которые содержат сериализованное содержимое базы данных. Таким образом, это похоже на создание резервной копии базы данных, но Django осознает, что ее проще использовать, и она принесет дополнительные преимущества, когда вы начнете выполнять такие вещи, как модульное тестирование.

Вы можете создать прибор из данных, которые в настоящее время находятся в вашей БД, используя django-admin.py dumpdata. По умолчанию данные представлены в формате JSON, но доступны и другие параметры, такие как XML. Хорошее место для хранения приборов - это подкаталог fixtures каталогов ваших приложений.

Вы можете загрузить прибор с помощью django-admin.py loaddata, но, что более важно, если у вашего прибора есть имя, например initial_data.json, оно будет автоматически загружено при выполнении syncdb, что избавит вас от необходимости импортировать его самостоятельно.

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

Конечно, это будет работать, когда вы добавляете атрибуты к моделям и столбцам в БД. Если вы удаляете столбец из базы данных, вам необходимо обновить свое устройство, чтобы удалить данные для этого столбца, что может быть непросто.

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

Answer 4

Я использую django-evolution. Предостережения включают в себя:

• Его автоматические предложения были равномерно прогнившими; и
• Его функция идентификации возвращает разные значения для одной и той же базы данных на разных платформах.

Тем не менее, я считаю, что пользовательский подход schema_evolution.py удобен. Чтобы обойти проблему отпечатка пальца, я предлагаю код как:

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

Если бы у меня было больше отпечатков пальцев и изменений, я бы перефакторил их. А до тех пор, если он станет чище, это украдет время разработки у чего-то другого.

РЕДАКТИРОВАТЬ: Учитывая, что я все равно вручную создаю свои изменения, я попробую dmigrations в следующий раз.

Answer 5

django-command-extensions - это библиотека django, которая предоставляет несколько дополнительных команд для manage.py. Одним из них является sqldiff, который должен дать вам sql, необходимый для обновления вашей новой модели. Однако он указан как «очень экспериментальный».

Answer 6

Django 1.7 (в настоящее время в разработке) - это добавление встроенной поддержки для миграции схемы с manage.py migrate и manage.py makemigrations (migrate устарела syncdb).

Answer 7

До сих пор в моей компании мы использовали ручной подход. То, что работает лучше для вас, во многом зависит от вашего стиля разработки.

У нас обычно не так много изменений схемы в производственных системах и несколько формализованных развертываний с серверов разработки на рабочие серверы. Всякий раз, когда мы разворачиваемся (10-20 раз в год), мы выполняем различие между текущей и будущей производственной веткой, просматривая весь код и отмечая, что необходимо изменить на производственном сервере. Необходимыми изменениями могут быть дополнительные зависимости, изменения в файле настроек и изменения в базе данных.

Это очень хорошо работает для нас. Автоматизировать все это - нишевое видение, но для нас оно сложное - возможно, мы могли бы управлять миграциями, но нам все равно нужно было бы обрабатывать дополнительные библиотеки, серверы, независимо от зависимостей.