Рабочий процесс Django при частом изменении моделей?

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

Вопрос

поскольку я обычно не занимаюсь предварительным дизайном своих моделей в проектах Django, в конечном итоге я часто изменяю модели и, таким образом, каждый раз удаляю свою тестовую базу данных (потому что "syncdb" никогда не изменит таблицы автоматически для вас).Ниже приведен мой рабочий процесс, и я хотел бы услышать о вашем.Любые мысли приветствуются..

  1. Измените модель.
  2. Удалите тестовую базу данных.(для меня всегда простая база данных sqlite.)
  3. Запустите "syncdb".
  4. Сгенерируйте некоторые тестовые данные с помощью кода.
  5. переход 1.

Вторичный вопрос по этому поводу..В случае, если ваш рабочий процесс похож на описанный выше, как вы выполняете 4.шаг?Вы генерируете тестовые данные вручную или в приложениях Django есть подходящая точка подключения, куда вы можете ввести код, генерирующий тестовые данные, при запуске сервера?\

ТИА.

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

Решение

Шаги 2 и 3 можно выполнить за один шаг:

manage.py reset appname

Шаг 4, насколько я понимаю, проще всего выполнить с помощью приспособления

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

Это работа для компании Django.Они удобны, потому что не зависят от базы данных, а тестовый жгут (и manage.py) имеет встроенную поддержку для них.

Чтобы использовать их:

  1. Настройте свои данные в своем приложении (назовите его "foo") с помощью инструмента администрирования
  2. Создайте каталог приспособлений в своем каталог приложения "foo"
  3. Тип: python manage.py dumpdata --indent=4 foo > foo/fixtures/foo.json

Теперь, после вашего этапа syncdb, вы просто вводите:

 python manage.py loaddata foo.json

И ваши данные будут созданы заново.

Если вы хотите, чтобы они были в тестовом примере:

class FooTests(TestCase):
    fixtures = ['foo.json']

Обратите внимание, что вам придется воссоздавать или вручную обновлять свои приспособления, если ваша схема кардинально изменится.

Вы можете прочитать больше о приспособлениях в документах django для Загрузка приспособления

Вот что мы делаем.

  1. Приложения именуются с указанием номера версии схемы. appa_2, appb_1, и т.д.

  2. Незначительные изменения не меняют номер.

  3. Основные изменения увеличивают это число.Syncdb работает.И может быть написан сценарий "переноса данных".

    def migrate_appa_2_to_3():
    for a in appa_2.SomeThing.objects.all():
        appa_3.AnotherThing.create( a.this, a.that )
        appa_3.NewThing.create( a.another, a.yetAnother )
    for b in ...

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

Юг - самый крутой.

Хотя старый добрый сброс работает лучше всего, когда данные не имеют значения.

http://south.aeracode.org/

Чтобы добавить к ответу Мэтью, я часто также использую пользовательский SQL для предоставления исходных данных в документированном виде здесь.

Django просто ищет файлы в <app>/sql/<modelname>.sql и запускает их после создания таблиц во время syncdb или sqlreset.Я использую пользовательский SQL, когда мне нужно сделать что-то вроде заполнения моих таблиц Django из других таблиц базы данных, отличных от Django.

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

Редактировать:Вообще-то, сейчас я использую South :-)

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