Initial SQL scripts (not data) for testing

[liwee]

I use quite a lot of database view (i.e. CREATE VIEW my_view) in my project. The only way to test the views is set keepdb=True, load the views and manage the test_database as a static entity forever. Ideally, creating a clean database from both fixtures and database views whenever I need to run a test makes more sense. Is it possible to add an option to load a sql script on create_test_db?

[Shai Berger]

How do you create the views in the non-test database?

Ideally, you'd do that in migrations with RunSQL operations. If you did that, you'd get the same views in your test databases.

If this solves your problem, please close the ticket as "invalid". If it doesn't, please elaborate.

[liwee]

The view script can be quite long, please see attached file. I keep the sql view script just above the relevant model in model.py. The contrib.admin takes cares of the UI. If a view change is required, I run the drop / create view script directly within the database, correcting errors I see on the spot.

​https://docs.djangoproject.com/en/1.8/howto/initial-data/
If you require data for a test case, you should add it using either a test fixture, or programmatically add it during the setUp() of your test case.

I wasn't aware that another method exist in RunSQL, thank you. To summarize, I would need to export the view schema from the live database, save the file, read the file and pass the contents to RunSQL to fake a migration whenever I need to test my views. Would all these excessive migration cause a problem? Is there anything wrong with my interpretation of RunSQL?

It just seems cleaner if I can get create_test_db to read the exported view schema directly or perhaps for create_test_db to extract the view schema directly from the live database.

[Tim Graham]

It sounds like you are on the right track with your understanding. If you need further help, please see TicketClosingReasons/UseSupportChannels.