mysite/settings.py 
 INSTALLED_APPS = ( 
     'Django.contrib.admin', 
     'Django.contrib.auth', 
     'Django.contrib.contenttypes', 
     'Django.contrib.sessions', 
     'Django.contrib.messages', 
     'Django.contrib.staticfiles', 
     'polls', 
 )

Ahora que Django sabe sobre nuestra app polls. Tendremos que ejecutar el siguiente comando:

$ python manage.py makemigrations polls

Como resultado de esta ejecución deberíamos obtener lo siguiente:

Migrations for 'polls': 
 0001_initial.py: 
 - Create model Pregunta 
 - Create model Opcion 
 - Add field pregunta to opcion

Al ejecutar el comando “makemigrations”, le estamos diciendo a “Django” que hemos realizado algunos cambios en nuestros modelos (en este caso, nuevos modelos) y que quisiéramos registrar esos cambios con una migración.

Las migraciones es la manera que tiene “Django” de guardar los cambios a nuestros modelos, por consiguiente también en el esquema de la base de datos. Si quisiéramos leer la migración de nuestro nuevo modelo, solo nos tendremos que dirigir al archivo “polls/migrations/0001_initial.py”. No son archivos que sean necesarios ser leídos pero por curiosidad no está mal hacerlo, estos ficheros están diseñados para ser editables a mano en caso de que se quiera hacer alguna modificación en la forma que “Django” aplica los cambios.

Django tiene un comando que ejecuta las migraciones y administra el esquema de base de datos automáticamente se trata del comando “migrate” que hablaremos de él un poco más adelante, ahora vamos a ver cuál es el código SQL que la migración va a ejecutar. El comando “sqlmigrate” tiene como entrada los nombres de migraciones y nos devuelve el código SQL respectivo:

$ python manage.py sqlmigrate polls 0001

Al ejecutar esta línea deberíamos ver algo parecido a lo siguiente (Aquí le hemos dado formato para que sea más legible):

BEGIN; 
  
 CREATE TABLE "polls_opcion" ( 
  
 "id" serial NOT NULL PRIMARY KEY, 
  
 " texto_opcion" varchar(200) NOT NULL, 
  
 " votos" integer NOT NULL 
  
 ); 
  
 CREATE TABLE "polls_pregunta" ( 
  
 "id" serial NOT NULL PRIMARY KEY, 
  
 " texto_pregunta" varchar(200) NOT NULL, 
  
 " fecha_publi" timestamp with time zone NOT NULL 
  
 ); 
  
 ALTER TABLE " polls_opcion " ADD COLUMN " pregunta_id" integer NOT NULL; 
  
 ALTER TABLE " polls_opcion " ALTER COLUMN " pregunta_id" DROP DEFAULT; 
  
 CREATE INDEX "polls_opcion_7aa0f6ee" ON "polls_ opcion" ("pregunta_id"); 
  
 ALTER TABLE "polls_opcion" 
  
 ADD CONSTRAINT "polls_opcion_pregunta_id_246c99a640fbbd72_fk_polls_pregunta_id" 
  
 FOREIGN KEY ("pregunta_id") 
  
 REFERENCES "polls_pregunta" ("id") 
  
 DEFERRABLE INITIALLY DEFERRED; 
  
  
  
 COMMIT;

La información que nos muestre el comando variará en función de que base de datos hayamos escogido al final. El ejemplo que os hemos mostrado corresponde con el código generado para  “PostgreSQL”. Los nombres de las tablas se generan automáticamente combinando el nombre de la app (polls) con el nombre, en minúsculas del modelo – pregunta y opción, aunque Django nos permite cambiar la manera de crear estos nombres.

Las claves primarias (IDs) se agregan automáticamente, también podemos indicar a “Django” que no lo haga si no queremos. Por defecto, “Django” añade “_id” al nombre del campo de clave, aunque al igual que en los casos anteriores podemos modificar este comportamiento si queremos. La relación de clave foránea se hace explícita mediante un “constraint FOREIGN KEY”. No os preocupéis por la parte del “DEFERRABLE”, esta parte indica a “PostgreSQL” no forzar la clave foránea hasta el final de la transacción.

Recordaros que todo este código se ajusta a la base de datos que estéis usando, por lo que no os tenéis preocupéis si el código es distinto, “Djando” aplicará a cada tipo de base de datos los campos específicos que correspondan. El comando “sqlmigrate” no va a ejecutar la migración en la base de datos, lo único que va a hacer es mostrar por pantalla el código SQL que “Django” va a ejecutar. Este comando nos será útil para comprobar que “Django” va a ejecutar el código correcto o para extraerlo y ejecutar nosotros mismos el código si queremos. Si queréis también podéis ejecutar “python manage.py check”, con este comando haremos que se compruebe el proyecto si realizar ninguna migración por si existiera algún error.

Ahora sí, vamos a ejecutar el comando “migrate” de nuevo para crear las tablas correspondientes a nuestros modelos en la base de datos:

$ python manage.py migrate 
  
 Operations to perform: 
  
 Synchronize unmigrated apps: staticfiles, messages 
  
 Apply all migrations: admin, contenttypes, polls, auth, sessions 
  
 Synchronizing apps without migrations: 
  
 Creating tables... 
  
 Running deferred SQL... 
  
 Installing custom SQL... 
  
 Running migrations: 
  
 Rendering model states... DONE 
  
 Applying <migration name>... OK

El comando “migrate” cogerá todas las migraciones que no se hayan ejecutado todavía y las ejecutará contra la base de datos. Esto es posible a que Django lleva un registro de las migraciones aplicadas.

Las migraciones son muy útiles ya que nos van a permitir ir cambiando nuestros modelos según va evolucionando el proyecto, además, de este modo no tendremos necesidad de borrar la base de datos o las tablas a crear. Vamos hacer un recordatorio de los tres pasos que hay que hacer para poder realizar cambios en nuestros modelos:

• Cambiar nuestros modelos (en models.py).
• Ejecutar “python manage.py makemigrations” para crear las migraciones correspondientes a los cambios en los modelos.
• Ejecutar “python manage.py migrate” para aplicar estos cambios en la base de datos.

El motivo por el que hay comandos separados para crear y aplicar migraciones es debido a que es necesario realizar “commit” de las migraciones en nuestro sistema de control de versiones y distribuirlas con nuestra app. Por lo que no solamente hacen nuestro desarrollo más simple, sino que también son reusables por otros desarrolladores y en producción.

Para tener la información completa de qué puede hacer la utilidad “manage.py”, podéis leer más en la documentación de “Django”.

Esto es todo por hoy, os dejamos que sigáis trabajando con los modelos y vayáis dando vuestros primeros pasos, comprobaréis que esto os ayudará mucho en el futuro. Para todos los que se acaban de incorporar indicarles que tenemos un índice con todos los capítulos del curso, ya que nunca es tarde para empezar.