Django 中的initial_data 夹具管理

发布于 2024-10-07 00:55:09 字数 313 浏览 3 评论 0原文

我正在开发的 django 项目有大量的initial_data 固定数据。默认情况下,自动加载数据的唯一方法似乎是在应用程序文件夹中放置一个名为 fixtures 的文件,并且该文件需要命名为 initial_data.ext (ext是 xml 或 json 或 yaml 或其他)。

我觉得这实在是太不灵活了。我宁愿有一个固定装置文件夹,然后在其中有一个initial_data 文件夹,然后在其中为该应用程序中的每个模型都有一个文件。或者有类似效果的东西。现在可以在 django 中执行此操作吗?或者也许是其他更好的固定装置组织方案。

The django projet I'm working on has a ton of initial_data fixture data. It seems by default the only way to have data load automatically is to have a file in your app folder called fixtures, and the file needs to be named initial_data.ext (ext being xml or json or yaml or something).

This is really unflexable, I think. I'd rather have a fixtures folder, and then inside that a initial_data folder, and then inside there, one file for each model in that app. Or something to that effect. IS this possible to do in django now? Or maybe some other scheme of better fixture organization.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

花开雨落又逢春i 2024-10-14 00:55:10

您可以根据需要重新组织初始数据装置,然后编写一个加载它们的 post_syncdb 信号处理程序。因此,它将根据您定义的逻辑自动加载到 syncdb 上。

请参阅: https://docs.djangoproject.com/en/1.3/参考/信号/#post-syncdb

You can reorganize your initial data fixtures however you want and then write a post_syncdb signal handler which loads them. So it will then be automatically loaded on syncdb, according to the logic defined by you.

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

仅此而已 2024-10-14 00:55:10

是的,您可以将灯具拆分为具有子文件夹结构的多个文件。您可以指定要加载的夹具文件并创建加载其中部分或全部的脚本。我之前已经这样做过,所以可以确认它是否有效。

示例:django-admin.py loaddata application/module/model.json

请参阅loaddata 文档以获取更多信息。

Yes, you can split fixtures into multiple files with subfolder structures. You can specify fixture files to load and create a script that loads some or all of them. I have done this before so can confirm that it works.

Example: django-admin.py loaddata application/module/model.json

See loaddata documentation for more information.

话少情深 2024-10-14 00:55:10

加载一个或两个额外的initial_data.json 的一种巧妙方法是在您的Django 项目中创建额外的空应用程序,该项目除了fixtures 文件夹和initial_data.json 文件之外什么都没有。如果您需要在其他应用程序的灯具之前加载该灯具,您可以将其命名为aa1。如果您需要另一个,您可以将其命名为 aa2。您的目录结构将如下所示:

aa1/
   fixtures/
      initial_data.json

aa2/
   fixtures/
      initial_data.json

myrealapp/
   fixtures/
      initial_data.json
...

您需要将应用添加到 settings.py 中的 INSTALLED_APPS

然后,您可以根据需要使用任意应用程序信息填充fixture_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.pysyncdb时,每个固定装置将按字母顺序自动加载。

正如我所提到的,这非常hacky,但如果您只需要几个额外的initial_data.json 文件并且需要能够控制它们的加载顺序,那么这是可行的。

A hacky way to load an additional initial_data.json or two is to create additional empty apps within your Django project that has nothing but the fixtures folder and the initial_data.json file. If you need the fixture loaded before the other apps' fixtures, you could name it something like aa1. If you need another one you could name it aa2. Your directory structure would look like this:

aa1/
   fixtures/
      initial_data.json

aa2/
   fixtures/
      initial_data.json

myrealapp/
   fixtures/
      initial_data.json
...

You would need to add the apps to INSTALLED_APPS in settings.py.

You can then populate the fixture_data.json files with arbitrary app information as necessary:

(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

When you run python manage.py syncdb, each of the fixtures will be loaded in automatically in alphabetical order.

As I mentioned, this is quite hacky, but if you only need a couple extra initial_data.json files and need to be able to control the order they are loaded in, this works.

黑寡妇 2024-10-14 00:55:09

根据我的经验,硬编码的装置编写起来很痛苦,维护起来也很痛苦。无论何时模型更改破坏了固定装置,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 模型存在所需的任何依赖项。这只是一个简单的示例,但该库可以处理非常复杂的模型结构。

In my experience, hard-coded fixtures are a pain to write and a pain to maintain. Wherever a model change breaks a fixture, the Django initial load will return a very unfriendly error message and you will end-up adding a bunch a of print's in the Django core in order to find where the problem is coming from.

One of the developer I work with has developed a very good library to overcome this problem, it's called django-dynamic-fixture and we really to love it. Here is how it works:

Suppose you have this models:

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

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

In order to create a book instance in your test, all you have to do is

from django_dynamic_fixture import get
from app import Book

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

The django-dynamic-fixture automatically creates for you any dependencies that are required for the Book model to exist. This is just a simple example but the library can handle very complex model structures.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文