Django 中的initial_data 夹具管理
我正在开发的 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您可以根据需要重新组织初始数据装置,然后编写一个加载它们的
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 onsyncdb
, according to the logic defined by you.See: https://docs.djangoproject.com/en/1.3/ref/signals/#post-syncdb
是的,您可以将灯具拆分为具有子文件夹结构的多个文件。您可以指定要加载的夹具文件并创建加载其中部分或全部的脚本。我之前已经这样做过,所以可以确认它是否有效。
示例:
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.加载一个或两个额外的initial_data.json 的一种巧妙方法是在您的Django 项目中创建额外的空应用程序,该项目除了fixtures 文件夹和initial_data.json 文件之外什么都没有。如果您需要在其他应用程序的灯具之前加载该灯具,您可以将其命名为
aa1
。如果您需要另一个,您可以将其命名为aa2
。您的目录结构将如下所示:您需要将应用添加到
settings.py
中的INSTALLED_APPS
。然后,您可以根据需要使用任意应用程序信息填充fixture_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 itaa2
. Your directory structure would look like this:You would need to add the apps to
INSTALLED_APPS
insettings.py
.You can then populate the fixture_data.json files with arbitrary app information as necessary:
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.
根据我的经验,硬编码的装置编写起来很痛苦,维护起来也很痛苦。无论何时模型更改破坏了固定装置,Django 初始加载都会返回一条非常不友好的错误消息,并且您最终将在 Django 核心中添加一堆打印内容,以便找到问题的根源。
与我合作的一位开发人员开发了一个非常好的库来解决这个问题,它被称为 django-dynamic -fixture,我们真的很喜欢它。它的工作原理如下:
假设您有以下模型:
为了在测试中创建书籍实例,您所要做的就是
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:
In order to create a book instance in your test, all you have to do is
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.