initial_data and post_syncdb conflicts

[David Cramer]

We've been working on switching our test suite to use some new "super
fixtures", which are really just global, test-only initial_data style
fixtures. To implement this we attach to the post_syncdb, and set a
runonce-per-db flag (since it seems to be the only available signal),
but we hit some issues with the way the process flow works for flush/
syncdb.

Basically, all the code goes:

{flush,syncdb} => {db actions} => emit post_syncdb => load
initial_data

In order for our hooks to work, we had to reorder load initial_data so
that it happened before the syncdb signal was sent out. The reason
being is that some of our fixture data relied on foreignkeys which
were present in initial_data.

My question is, would it be reasonable to change this upstream (both
in syncdb and flush), or would it be better to possibly add some
additional signals?

[Stephen Burrows]

Perhaps I'm missing something... initial_data is "test-only", right?
As opposed to other fixtures which should always be loaded? Then why
would the other fixtures rely on the initial_data?

[David Cramer]

initial_data gets populated whenever you migrate your database (e.g.
syncdb, reset, etc). These, at least in my opinion, can be see as
default database fixtures that you should be allowed to have an
expectation of their existence. Gven that, we have *test only*
fixtures (not initial_data) that get loaded that reference (with
foreign keys) rows that are created in the initial_data load.

On Aug 19, 1:12 am, Stephen Burrows <stephen.r.burr...@gmail.com>
wrote: