El libro de Django 1.0

5.7. Instalar el modelo

Ya escribimos el código; creemos ahora las tablas en la base de datos. Para hacerlo, el primer paso es activar estos modelos en nuestro proyecto Django. Hacemos esto agregando la aplicación books a la lista de aplicaciones instaladas en el archivo de configuración.

Edita el archivo settings.py otra vez, y examina la variable de configuración INSTALLED_APPS. INSTALLED_APPS le indica a Django qué aplicaciones están activadas para un proyecto determinado. Por omisión, se ve como esto:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
)

Temporalmente, comenta estos cuatro strings poniendo un carácter (#) al principio. (Están incluidos por omisión porque es frecuente usarlas, pero las activaremos y las discutiremos más adelante) Cuando termines, modifica las configuraciones por omisión de MIDDLEWARE_CLASSES y TEMPLATE_CONTEXT_PROCESSORS. Éstas dependen de algunas de las aplicaciones que hemos comentado. Entonces, agrega 'mysite.books' a la lista INSTALLED_APPS, de manera que la configuración termine viéndose así:

MIDDLEWARE_CLASSES = (
#    'django.middleware.common.CommonMiddleware',
#    'django.contrib.sessions.middleware.SessionMiddleware',
#    'django.contrib.auth.middleware.AuthenticationMiddleware',
#    'django.middleware.doc.XViewMiddleware',
)

TEMPLATE_CONTEXT_PROCESSORS = ()
#...

INSTALLED_APPS = (
    #'django.contrib.auth',
    #'django.contrib.contenttypes',
    #'django.contrib.sessions',
    #'django.contrib.sites',
    'mysite.books',
)

(Como aquí estamos tratando con una tupla de un solo elemento, no olvides la coma final. De paso, los autores de este libro prefieren poner una coma después de cada elemento de una tupla, aunque la tupla tenga sólo un elemento. Esto evita el problema de olvidar comas, y no hay penalización por el use de esa coma extra)

'mysite.books' se refiere a la aplicación books en la que estamos trabajando. Cada aplicación en INSTALLED_APPS es representada por su ruta Python completa — esto es, la ruta de paquetes, separados por puntos, que lleva al paquete de la aplicación.

Ahora que la aplicación Django ha sido activada en el archivo de configuración, podemos crear las tablas en nuestra base de datos. Primero, validemos los modelos ejecutando este comando:

python manage.py validate

El comando validate verifica si la sintaxis y la lógica de tus modelos son correctas. Si todo está bien, verás el mensaje 0 errors found. Si no, asegúrate de haber escrito el código del modelo correctamente. La salida del error debe brindarte información útil acerca de qué es lo que está mal en el código.

Cada vez que piensas que tienes problemas con tus modelos, ejecuta python manage.py validate. Tiende a capturar todos los problemas comunes del modelo.

Si tus modelos son válidos, ejecuta el siguiente comando para que Django genere sentencias CREATE TABLE para tus modelos en la aplicación books (con sintaxis resaltada en colores disponible si estás usando Unix):

python manage.py sqlall books

En este comando, books es el nombre de la aplicación. Es lo que hayas especificado cuando ejecutaste el comando manage.py startapp. Cuando ejecutes el comando, debes ver algo como esto:

BEGIN;
CREATE TABLE "books_publisher" (
    "id" serial NOT NULL PRIMARY KEY,
    "name" varchar(30) NOT NULL,
    "address" varchar(50) NOT NULL,
    "city" varchar(60) NOT NULL,
    "state_province" varchar(30) NOT NULL,
    "country" varchar(50) NOT NULL,
    "website" varchar(200) NOT NULL
);
CREATE TABLE "books_book" (
    "id" serial NOT NULL PRIMARY KEY,
    "title" varchar(100) NOT NULL,
    "publisher_id" integer NOT NULL REFERENCES "books_publisher" ("id"),
    "publication_date" date NOT NULL
);
CREATE TABLE "books_author" (
    "id" serial NOT NULL PRIMARY KEY,
    "salutation" varchar(10) NOT NULL,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(40) NOT NULL,
    "email" varchar(75) NOT NULL,
    "headshot" varchar(100) NOT NULL
);
CREATE TABLE "books_book_authors" (
    "id" serial NOT NULL PRIMARY KEY,
    "book_id" integer NOT NULL REFERENCES "books_book" ("id"),
    "author_id" integer NOT NULL REFERENCES "books_author" ("id"),
    UNIQUE ("book_id", "author_id")
);
CREATE INDEX books_book_publisher_id ON "books_book" ("publisher_id");
COMMIT;

Observa lo siguiente:

  • Los nombres de tabla se generan automáticamente combinando el nombre de la aplicación (books) y el nombre en minúsculas del modelo (publisher, book, y author). Puedes sobreescribir este comportamiento, como se detalla en el Apéndice B.
  • Como mencionamos antes, Django agrega una clave primaria para cada tabla automáticamente — los campos id. También puedes sobreescribir esto.
  • Por convención, Django agrega "_id" al nombre de campo de las claves foráneas. Como ya puedes imaginar, también puedes sobreescribir esto.
  • La relación de clave foránea se hace explícita con una sentencia REFERENCES
  • Estas sentencias CREATE TABLE son adaptadas a medida de la base de datos que estás usando, de manera que Django maneja automáticamente los tipos de campo específicos de cada base de datos, como auto_increment (MySQL), serial (PostgreSQL), o integer primary key (SQLite), por ti. Lo mismo sucede con el uso de las comillas simples o dobles en los nombres de columna. La salida del ejemplo está en la sintaxis de PostgreSQL.

El comando sqlall no crea ni toca de ninguna forma tu base de datos — sólo imprime una salida en la pantalla para que puedas ver qué SQL ejecutaría Django si le pidieras que lo hiciera. Si quieres, puedes copiar y pegar este fragmento de SQL en tu cliente de base de datos, o usa los pipes de Unix para pasarlo directamente. De todas formas, Django provee una manera más fácil de confirmar el envío del SQL a la base de datos. Ejecuta el comando syncdb de esta manera:

python manage.py syncdb

Verás algo como esto:

Creating table books_publisher
Creating table books_book
Creating table books_author
Installing index for books.Book model

El comando syncdb es una simple sincronización de tus modelos hacia tu base de datos. El mismo examina todos los modelos en cada aplicación que figure en tu variable de configuración INSTALLED_APPS, verifica la base de datos para ver si las tablas apropiadas ya existen, y las crea si no existen. Observa que syncdb no sincroniza los cambios o eliminaciones de los modelos; si haces un cambio o modificas un modelo, y quieres actualizar la base de datos, syncdb no maneja esto. (Más sobre esto después.)

Si ejecutas python manage.py syncdb de nuevo, nada sucede, porque no has agregado ningún modelo a la aplicación books ni has incorporado ninguna aplicación en INSTALLED_APPS. Ergo, siempre es seguro ejecutar python manage.py syncdb — no hará desaparecer cosas.

Si estás interesado, toma un momento para bucear en el cliente de línea de comandos de tu servidor de bases de datos y ver las tablas que creó Django. Puedes ejecutar manualmente el cliente de línea de comandos (ej.: psql para PostgreSQL) o puedes ejecutar el comando python manage.py dbshell, que deducirá qué cliente de linea de comando ejecutar, dependiendo de tu configuración DATABASE_SERVER. Esto último es casi siempre más conveniente.