Как создать для каждого проекта initial_data светильников в Django 1.7+

До Django 1.7 я использовал для определения fixtures каталога для каждого проекта в настройках:Как создать для каждого проекта initial_data светильников в Django 1.7+

FIXTURE_DIRS = ('myproject/fixtures',)

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

Теперь с Django 1.7, initial_data светильники устарели, suggesting включить data migrations вместе с миграцией схемы приложения; не оставляя очевидного выбора для глобальных исходных данных для каждого проекта.

Кроме того, новый migrations framework устанавливает все стандартные начальные данные, светильники перед исполняющих миграции для совместимых приложений (в том числе django.contrib.auth приложения). Это приводит к тому, что мой прибор, содержащий группы по умолчанию, составляет сбой установки, так как таблица auth_group еще не указана в БД.

Любые предложения о том, как (изящно) сделать светильники после всех миграций или, по крайней мере, после миграции приложений через приложение? Или любые другие идеи для решения этой проблемы? Я нахожу приспособления отличным способом для предоставления исходных данных и хотел бы иметь простой и чистый способ объявить их для автоматической установки. Новый RunPython просто слишком громоздкий, и я считаю его излишним для большинства целей; и, по-видимому, он доступен только для миграции приложений.

источник

2014-09-13 Jozef Knaperek

Поскольку это устарело, это, вероятно, будет немного неудобно. Один из вариантов может заключаться в создании минимального приложения для загрузки только исходных данных, создания переноса и в RunPython, для вызова любых функций, которые Django использует для загрузки светильников. Таким образом, вы также можете указать зависимости в своей миграции. Вероятно, это связано с серьезными копаниями в исходном коде Django. –

Да, я хоть и создаю какое-то приложение * meta * в качестве последнего средства и создаю там миграции (но это все еще некрасиво). Подумайте, почему новый Django, по крайней мере, не предоставляет стандартный способ ** декларативно ** задавать приборы, которые будут загружаться вместе с новыми Migrations. –

Где-то на SO было предложено повторно использовать файлы артефактов pre-1.7 json/xml. У вас будет минимальное приложение с переносом данных, а затем проанализируйте существующие существующие json/xml-инструменты и создайте записи из них. Это должно быть то, что произошло до-1.7 в любом случае. – 2014-10-09 09:04:57

Если вы абсолютно хотите использовать светильники, просто используйте RunPython и call_command в ваших миграциях данных.

from django.db import migrations 
from django.core.management import call_command 

def add_data(apps, schema_editor): 
    call_command('loaddata', 'thefixture.json') 

def remove_data(apps, schema_editor): 
    call_command('flush') 


class Migration(migrations.Migration): 

    dependencies = [ 
     ('roundtable', '0001_initial'), 
    ] 

    operations = [ 
     migrations.RunPython(
      add_data, 
      reverse_code=remove_data), 
    ]

Однако это Рекоммендуемый для загрузки данных с помощью кода питона и Django ORM, как вы не должны столкнуться с проблемами целостности.

Source.

источник

2014-11-14 12:09:55 Antwan

Это правильный ответ, и, похоже, это отличная дискуссия по этой теме. http://andrewsforge.com/article/upgrading-django-to-17/part-2-migrations-in-django-16-and-17/#initial-data-fixtures-and-data-migrations – shacker

Я просто смотрел [talk] (https://www.youtube.com/watch?v=bjIXZ-XX2SM) Эндрю Пинкхэма, который объясняет это красиво, так что это действительно похоже на путь. Как он говорит: «Система initial_data является проблемой при использовании в тандеме с миграциями»; поэтому «Система initial_data ушла, но приборы нет». –

предупреждение: команда «flush», как показано здесь, удаляет _all_ данные, а не только данные от перенаправления вперед – wim

Я рекомендую использовать фабрики вместо светильников, они беспорядок и трудно поддерживать, лучше использовать FactoryBoy с Django.

источник

2014-10-23 16:12:16 codeadict

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

Как создать для каждого проекта initial_data светильников в Django 1.7+

ответ

Смежные вопросы