Tuesday, January 31, 2012

Python & Django - Activating models

Activating models

That small bit of model code gives Django a lot of information. With it, Django is able to:
§                                 Create a database schema (CREATE TABLE statements) for this app.
§                                 Create a Python database-access API for accessing Poll and Choice objects.
But first we need to tell our project that the polls app is installed.
Philosophy
Django apps are "pluggable": You can use an app in multiple projects, and you can distribute apps, because they don't have to be tied to a given Django installation.
Edit the settings.py file again, and change the INSTALLED_APPS setting to include the string 'polls'. So it'll look like this:
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'polls'
)
Now Django knows to include the polls app. Let's run another command:
python manage.py sql polls
You should see something similar to the following (the CREATE TABLE SQL statements for the polls app):
BEGIN;
CREATE TABLE "polls_poll" (
    "id" serial NOT NULL PRIMARY KEY,
    "question" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id"),
    "choice" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
COMMIT;
Note the following:
§                                 The exact output will vary depending on the database you are using.
§                                 Table names are automatically generated by combining the name of the app (polls) and the lowercase name of the model -- poll and choice. (You can override this behavior.)
§                                 Primary keys (IDs) are added automatically. (You can override this, too.)
§                                 By convention, Django appends "_id" to the foreign key field name. Yes, you can override this, as well.
§                                 The foreign key relationship is made explicit by a REFERENCES statement.
§                                 It's tailored to the database you're using, so database-specific field types such as auto_increment(MySQL), serial (PostgreSQL), or integer primary key (SQLite) are handled for you automatically. Same goes for quoting of field names -- e.g., using double quotes or single quotes. The author of this tutorial runs PostgreSQL, so the example output is in PostgreSQL syntax.
§                                 The sql command doesn't actually run the SQL in your database - it just prints it to the screen so that you can see what SQL Django thinks is required. If you wanted to, you could copy and paste this SQL into your database prompt. However, as we will see shortly, Django provides an easier way of committing the SQL to the database.
If you're interested, also run the following commands:
§                                 python manage.py validate -- Checks for any errors in the construction of your models.
§                                 python manage.py sqlcustom polls -- Outputs any custom SQL statements (such as table modifications or constraints) that are defined for the application.
§                                 python manage.py sqlclear polls -- Outputs the necessary DROP TABLE statements for this app, according to which tables already exist in your database (if any).
§                                 python manage.py sqlindexes polls -- Outputs the CREATE INDEX statements for this app.
§                                 python manage.py sqlall polls -- A combination of all the SQL from the sql, sqlcustom, andsqlindexes commands.
Looking at the output of those commands can help you understand what's actually happening under the hood.
Now, run syncdb again to create those model tables in your database:

No comments: