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

StackOverflow https://stackoverflow.com/questions/35991

  •  09-06-2019
  •  | 
  •  

Вопрос

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

SyncDB не будет изменять существующие таблицы

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

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

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

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

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

Есть идеи?

Это было полезно?

Решение

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

Кроме того, два новых проекта на карте: Simplemigrations и Миграционный.

Другие советы

Вручную, выполняющие изменения в SQL, и сброс/перезагрузка-это варианты, но вы также можете проверить некоторые пакеты схемы-эволюции для Django. Самые зрелые варианты - это Джанго-эволюция и Юг.

РЕДАКТИРОВАТЬ: Эй, вот приходит Dmigrations.

ОБНОВЛЯТЬ: Так как этот ответ был изначально написан, Джанго-эволюция и Dmigrations как прекратили активное развитие, так и Юг стал де-факто стандартом миграции схемы в Джанго. Части юга могут быть даже интегрированы в Джанго в течение следующего или двух.

ОБНОВЛЯТЬ: Структура миграции схемы, основанная на Юге (и написанном Эндрю Годвином, автором юга), включена в Django 1.7+.

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

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

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

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

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

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

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

Я использовал 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 в следующий раз.

Django-Command-Extensions это библиотека Django, которая дает некоторые дополнительные команды для Manage.py. Одним из них является SQLDIFF, который должен дать вам SQL, необходимый для обновления вашей новой модели. Это, однако, перечислен как «очень экспериментальный».

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top