Custom SQL fixtures appear to be loaded in the wrong order.

[David Rogers]

When using custom SQL fixtures for loading SQL into the database (i.e. a VIEW for an unmanaged Model class or SQL INSERT / UPDATE statements), there are two filenames that can be used:

• [model_name].sql
• [model_name].[db_driver].sql

The latter is reserved for RDBMS-specific SQL statements that might differ from the standard, such as use of CREATE RULE for VIEWs in Postgres vice CREATE TRIGGER in SQLite. If _both_ files are used, the order in which the two are loaded and passed to the database is undesirable.

EXPECTED: If I use both a generic SQL fixture _and_ a RDBMS-specific SQL fixture, the generic fixture should be loaded first (i.e. for VIEW or TABLE definitions), then the other.

ACTUAL: Django consistently loads the driver-specific file _before_ the generic SQL fixture, instead. This can lead to unnecessary code duplication or failure.

[Russell Keith-Magee]

The order is undesirable *for you*. The other order is just as desirable under different circumstances. For example, if you have some unusual table requirements, you may need to do some db-specific ALTER TABLE statements before you do some generic data loading. That's a fairly simple example that demonstrates that the current order is "correct".

In addition, loading of data via SQL is something that we're trying to discourage; the preferred approach is to use fixtures.

Given that Django (a) has a preferred solution that avoids the problem you describe, and (b) can't fix the problem you describe in a generic way without allowing for multiple custom SQL entry points (i.e., a pre-generic and post-generic SQL hook, which itself would need pre-specific and post-specific hooks, and so on...), I'm going to close this wontfix. If you feel there is a broader issue that needs to be addressed, feel free to start a discussion on Django-dev.

[David Rogers]

What is the preferred method of loading custom SQL structures, such as "CREATE VIEW" or "CREATE OR REPLACE FUNCTION", that are intended to be exposed as Django (unmanaged) Models? For that matter, what is the preferred method for loading custom SQL for _any_ unmanaged Model? From everything I've read, using SQL fixtures to load those SQL statements automatically when the Model is registered is how it's done. Please correct me if I'm wrong.

If there's _not_ a method for doing so with Django, perhaps I'll propose that feature and submit some code. I'll also address the mailing list and the IRC channel with my question. Thanks.