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

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

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

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

ТИА.

6 Solutions collect form web for “Рабочий процесс 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 для загрузки Fixture

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

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

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

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

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

http://south.aeracode.org/

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

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

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

Изменить: На самом деле, я использую Юг сейчас 🙂

 
Interesting Posts for Van-Lav
Python - лучший язык программирования в мире.