Creating a table if it doesn't exist
Oliver Lavery
Building the database is non-trivial however, and the SQL for building the schema was some clever constraints that I doubt django will re-create if I build the schema from the model. I was thinking it'd be elegant to detect if the database exists before the models are referenced, and create it from SQL data if it doesn't. Right now if I ever move the app to another server I have a few ugly manual steps piping SQL into the db... this won't work for production.
I'm a little fuzzy on django's execution order, though. What would be the safest place to do this? Initialization code in the model module seems like the most obvious choice, but I'm a bit uncomfortable being in the dark as to how django initializes within mod_python. Where's the best spot for app initialization and teardown code?
Tia,
~ol
lbolo...@gmail.com
> I'm a little fuzzy on django's execution order, though. What would be the
> safest place to do this? Initialization code in the model module seems like
> the most obvious choice, but I'm a bit uncomfortable being in the dark as to
> how django initializes within mod_python. Where's the best spot for app
> initialization and teardown code?
Make yourself a build & deploy script that tries to target a "build in
1 step".
Where i work we have something we call db kits, basically we store the
dump of the database schema + all the stored procedures, etc... in the
versioning system. Then there's a script that collects them and applies
them to the database. There's still someone that has to copy the code
from the repository and build it with nant and configure it, etc...
For my own projects i was thinking about doing the same thing as a db
kit in a database agnostic way, probably using SQLAlchemy.
Also something like WAF[1] may be of help in a non .NET world to help
automatize some tasks.
The bottom line is building an installer for your stuff. I believe
that's something that software like Capistrano tries to solve.
Lorenzo
--
[1] http://freehackers.org/~tnagy/bksys.html
Russell Keith-Magee
> I'm a little fuzzy on django's execution order, though. What would be the
> safest place to do this? Initialization code in the model module seems like
> the most obvious choice, but I'm a bit uncomfortable being in the dark as to
> how django initializes within mod_python. Where's the best spot for app
> initialization and teardown code?
Some details that might be helpful:
1) Django tables are only created when you run 'manage.py
syncdb/install', etc. When you run 'manage.py runserver' (or when you
use the mod_python interface) Django assumes that the correct tables
already exist and are ready for use.
2) Before syncdb attempts to create a table, it searches to see if
that table of the required name already exists. If it does, it skips
creation of that table. If you have manually created a table of the
named expected by Django (either by squatting in the
'appname_modelname' namespace, or by specifying a db_table in your
Meta section for a model, Django will not delete/overwrite your table.
3) If you want to use Django's tables as a starting point, but add
extra columns/triggers/modifications, you can create a directory
called 'sql' in your models directory, and put 'modelname.sql' files
in that directory. After Django adds 'modelname' to the database, the
contents of this sql file will be executed on your database. This
provides a clean hook for modifying Django's default tables.
4) Another way to modify the default database or add data to the
database is to use a management.py file. If you put a file named
management.py in your model directory, this file will be loaded when
the applicaiton is synchronized; you can use this file to register
listeners on the post_syncdb event, and respond accordingly. Look in
to the contrib.auth package and search the mailing list archive if you
want more details on this.
Yours,
Russ Magee %-)