Code

Opened 3 years ago

Last modified 3 years ago

#15578 new Cleanup/optimization

loaddata and processing order of fixtures

Reported by: lsaffre Owned by: nobody
Component: Documentation Version: 1.2
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

As the documentation for loaddata correctly says: "the order in which fixture files are processed is undefined."
That's a pity because I use fixtures to provide combinable and interdependent sets of demo data.

Would it be difficult to implement a rule for the order in which fixtures are loaded?
I'd suggest the following rule:
If there are 3 applications "a", "b" and "c" and you invoke

manage.py loaddata foo bar baz

(or you specify

fixtures = ['foo','bar','baz']

in a TestCase, then loaddata would first load all fixtures 'foo' for all applications, then all fixtures named 'bar', then all fixtures 'baz'.

Attachments (1)

doc_patch.diff (1.0 KB) - added by trez 3 years ago.
doc path for fixture ordering - maybe just a draft

Download all attachments as: .zip

Change History (8)

comment:1 Changed 3 years ago by lukeplant

  • Type set to New feature

comment:2 Changed 3 years ago by lukeplant

  • Severity set to Normal

comment:3 Changed 3 years ago by jacob

  • Component changed from Uncategorized to Core (Management commands)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed
  • Type changed from New feature to Cleanup/optimization

Interesting - that clause in the docs dates from r4659, the original commit of fixtures. But as far as I can tell, it's never been true: the code actually does exactly what you suggest and does load fixtures in the order given. I think we should just strike that paragraph from the docs, but I'd like to see if Russ remembers why he wrote that in the first place.

comment:4 Changed 3 years ago by russellm

  • Component changed from Core (Management commands) to Documentation
  • Triage Stage changed from Design decision needed to Accepted

The statement is still accurate -- just imprecise.

Firstly, fixtures *are* loaded in the "foo", "bar", "baz" order. However, "foo" doesn't refer to a single fixture; any fixture named "foo" *in any app* will be loaded. This is what allows the "initial_data" load to occur, but the same trick works for any fixture name. The admonition that is there is intended to wave people off of the idea that specifying fixture order is enough to guarantee 100% predictable. This isn't true -- you also need to take into account the order in which applications are defined.

The admonition was probably also a partial "commit to nothing" statement, giving us some wiggle room if we needed to change things. Fixtures have been in the water for long enough that this reason no longer holds.

So I agree - fixing the documentation is all that is required here. Just deleting the line is the simple approach; a slightly better approach would expand the statement to include a the app ordering part of the process.

comment:5 Changed 3 years ago by lsaffre

Glad to read that this is just a documentation bug. Maybe something like this:

If several fixtures are specified, then the application order is also important: the first fixture is loaded first for all applications (in the order specified by INSTALLED_APPS), then the second fixture, and so on.

Changed 3 years ago by trez

doc path for fixture ordering - maybe just a draft

comment:6 Changed 3 years ago by trez

  • Easy pickings unset
  • Has patch set
  • UI/UX unset

The patch attached contains this explanation:

SQL data files are executed in the same order than their ordering
in the fixtures.

For example:

fixtures = ['foo','bar','baz']
foo will be executed first then bar, then baz.

However, fixtures are not loaded for one application but for any
applications which contains this fixture.

Therefore, you should also take into account the order in which application
are defined.

Hope this help but may surely be crystal clear with some improvements

comment:7 Changed 3 years ago by aaugustin

  • Patch needs improvement set

There are a couple issues with this patch.

It should change the following sentences in ref/django-admin.txt:

  • "Note that the order in which fixture files are processed is undefined." — the section about fixtures in topics/testing.txt links to this paragraph.
  • "Note that the order in which the SQL files are processed is undefined." — not sure about this one, but if the order is deterministic, let's fix it too.

Finally, the patch isn't relative to the trunk directory of the source distribution.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.