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

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

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

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

ТИА.

Ответы

Ответ 1

Шаги 2 и 3 можно сделать за один шаг:

manage.py reset appname

Шаг 4, с моей точки зрения, наиболее легко управляется с помощью fixtures

Ответ 2

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

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

  • Настройте свои данные в своем приложении (вызов это "foo" ), используя инструмент admin
  • Создайте каталог светильников в своем Каталог приложений "foo"
  • Тип: 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 вы можете узнать для Загрузка Fixture

Ответ 3

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

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

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

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

    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 ...

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

Ответ 4

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

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

http://south.aeracode.org/

Ответ 5

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

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

Ответ 6

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

Изменить: На самом деле, теперь я использую Юг: -)