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

Question

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

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

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

ТИА.

Answer 1

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

manage.py reset appname

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

Answer 2

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

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

1. Настройте свои данные в своем приложении (звоните это "фу") с помощью админки
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 docs для Загрузка приспособлений

Answer 3

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

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

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

Answer 4

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

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

http://south.aeracode.org/

Answer 5

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

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

Answer 6

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

Редактировать: На самом деле, я сейчас использую Юг: -)