Whenever someone in the Microsoft development world has needed to demonstrate virtually anything utilising a database, the Microsoft Northwind database has been used.
The beauty of the Northwind database being so widely recognised and frequently reused, is that developers around the world don’t need to concern themselves with learning or understanding a new database schema every time another developer wishes to provide an example. Instead, the developer doing the example can simply state that his or her example is based off of the Northwind database and by proxy of its popularity, the majority of the readers will immediately understand.
Since the Microsoft Northwind database is so popular and used so widely, it seemed like a good idea to make it available for anyone wanting to do some simple examples using Django. I’ll be releasing the initial version of it in the coming days, keep your eyes peeled if you’re interested.
Django provides functionality through manage.py to manage the database that you’re using. The various utility commands range from building your database using syncdb command to tearing it down using flush.
The functionality to manage the database through Django is great, however it’s often required to load initial data into a database when it is first created. The initial data might be used for running unit tests against or actually providing some useful default information into a system every time it is built.
Django provides two mechanisms to handle this functionality:
- Initial SQL
- The initial SQL way relies on providing a plain text file with SQL statements in it. The SQL files are located in a folder named ‘sql’ under each application. There is no guarantee on what order the files will be executed, just that they will be executed some time after the database creation has been completed. Each SQL file provided should be named after the lower case version of the model name it is for; more about this point later.
- Fixtures are essentially blocks of data, which do not necessarily need to be related to one another. Django supports various formats for the fixture files, ranging from JSON to YAML but accepts anything which is has a serialiser for. Using fixtures means that the developer can group various bits of information together, lets say specifically for a unit test and have it loaded each time the unit test is run. As a convenient feature, Django provides a way to dump the data currently in the database into a fixture file in whatever format you’d like and then reload it at a later time using the loaddata command.
Not knowing any better, I followed the SQL path initially simply because it was familiar to me. Everything was going just fine, every model I created I produced a useful collection of SQL statements to match. This process continued until the model definitions got a little more complex and I hit a wall when I defined a many to many relationship.
The problem was pretty straight forward, the SQL method states that the SQL file must be named after the lower case name of the model that it refers to. There is no problem with this until you produce a model that automatically generates tables, such as a many to many table relationship. I tried a number of different file names, however since the table is automatically generated off an existing model; I couldn’t find a file named that worked.
Given how complete Django seems to be in general, I’ll be surprised if I don’t find out that there is a way to do this down the road. Until that road is crossed though, I moved onto using fixtures to load the initial data into the database and it works a treat. I can conveniently use the automatic admin that Django provides to create some sample data and then just dump it into a fixture to reload at a later time.