Управление фикстурой initial_data в django

Проект django, над которым я работаю, имеет массу данных фикстуры initial_data. Кажется, что по умолчанию единственный способ автоматической загрузки данных - это иметь файл в папке вашего приложения с именем fixtures, а файл должен называться initial_data.ext (расширение - xml, json, yaml или что-то в этом роде).

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


python django fixture
person priestc    schedule 09.12.2010    source источник

Ответы (4)


arrow_upward
10
arrow_downward

По моему опыту, жестко закодированные фикстуры сложно писать и сложно поддерживать. Везде, где изменение модели ломает фикстуру, первоначальная загрузка Django вернет очень недружественное сообщение об ошибке, и в конечном итоге вы добавите кучу отпечатков в ядро ​​Django, чтобы найти источник проблемы.

Один из разработчиков, с которым я работаю, разработал очень хорошую библиотеку для решения этой проблемы, она называется django-dynamic. -fixture и нам это очень нравится. Вот как это работает:

Предположим, у вас есть эти модели:

class Author(models.Model):
    name = models.CharField()

class Book(models.Model):
    author = models.ForeingKey(Author, required=True)
    title = models.CharField()

Чтобы создать экземпляр книги в своем тесте, все, что вам нужно сделать, это

from django_dynamic_fixture import get
from app import Book

class MyTest(TestCase):
    def setUp(self):
        self.book = get(Book)

Django-dynamic-fixture автоматически создает для вас любые зависимости, необходимые для существования модели Book. Это всего лишь простой пример, но библиотека может работать с очень сложными структурами моделей.

person Cesar Canassa    schedule 01.07.2011
comment
как вы относитесь к настройке и демонтажу, особенно при работе с djano-nose? - person whatf; 19.09.2012
comment
@whatf Я не уверен, что вы спросили. В примере, который я привел, уже есть пример setUp. Использование django-nose не изменит этого - person Cesar Canassa; 19.09.2012
comment
внутри класса до и после запуска каждого из тестовых определений вызываются методы setUp и tearDown. Из-за чего тесты идут медленно. django_nose, однако оптимизирует, его. Пожалуйста, обратитесь к документу. Мне просто любопытно, как бы вы позаботились об этих оптимизациях, используя DDF. - person whatf; 20.09.2012

arrow_upward
2
arrow_downward

Вы можете реорганизовать свои исходные данные, как хотите, а затем написать обработчик сигнала post_syncdb, который их загрузит. Таким образом, он будет автоматически загружен на syncdb в соответствии с определенной вами логикой.

См.: https://docs.djangoproject.com/en/1.3/ref/signals/#post-syncdb

person Botond Béres    schedule 05.07.2011

arrow_upward
0
arrow_downward

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

Пример: django-admin.py loaddata application/module/model.json

Дополнительную информацию см. в документации loaddata.

person vls    schedule 09.12.2010
comment
nbv4: Я обнаружил, что наиболее удобным методом решения этой проблемы при разработке является создание сценария сброса базы данных, который сначала очистит базу данных (зависит от базы данных), затем создаст структуры базы данных (syncdb) и, наконец, загрузит фикстуры (loaddata). - person vls; 09.12.2010

arrow_upward
0
arrow_downward

Хитрый способ загрузить дополнительный файл initial_data.json или два — создать дополнительные пустые приложения в вашем проекте Django, в котором нет ничего, кроме папки с фикстурами и файла initial_data.json. Если вам нужно, чтобы фикстура загружалась перед фикстурами других приложений, вы можете назвать ее, например, aa1. Если вам нужен еще один, вы можете назвать его aa2. Ваша структура каталогов будет выглядеть так:

aa1/
   fixtures/
      initial_data.json

aa2/
   fixtures/
      initial_data.json

myrealapp/
   fixtures/
      initial_data.json
...

Вам нужно будет добавить приложения в INSTALLED_APPS в settings.py.

Затем вы можете заполнить файлы fix_data.json произвольной информацией о приложении по мере необходимости:

(virtualenv) ./manage.py dumpdata --indent=4 auth > aa1/fixtures/initial_data.json

(virtualenv) ./manage.py dumpdata --indent=4 oauth2 > aa2/fixtures/initial_data.json

(virtualenv) ./manage.py dumpdata --indent=4 myrealapp > myrealapp/fixtures/initial_data.json

Когда вы запускаете python manage.py syncdb, каждый из приборов будет загружен автоматически в алфавитном порядке.

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

person Ryan Rapp    schedule 29.06.2014