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 <[email protected]> wrote: > 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? > > On Aug 18, 4:15 pm, David Cramer <[email protected]> wrote: > > > > > > > > > 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? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
