On Thu, Feb 12, 2009 at 2:54 PM, Ludvig Ericson

It has consequences because you are proposing to change the order in
which indexes and custom SQL are applied. Any code that depends on the
existing order will be affected.

If it has the potential to break _any_ code, it is an unacceptable
change. The Django core developers have stated that we will maintain
backwards compatibility of the v1.0 interface, so any change with even
the _potential_ to affect backwards compatibility will need to be
checked very carefully.

However, the larger point is that you don't get to make that decision
about whether a change is acceptable or not. You can discuss a change
and make a recommendation, but ultimately the decision needs to be
made by a core developer. The Design Decision Required triage state
exists for exactly this reason.

This is what needs to be confirmed, and given that it is a non-trivial
change, your decision needs to be confirmed by a core developer. I am
willing to be convinced, but you will need to prove to me that there
is no backwards compatibility problem here. The discussion in this
thread so far hasn't done that.

To answer the original question (why is it done in this order) -
mostly historical reasons. Originally, Django didn't have fixtures, so
initial data were all loaded from initial SQL. It's generally faster
to insert data and then add indicies, hence the order. When Django
added fixtures, the order wasn't changed.

Yours,
Russ Magee %-)