Antonio Melé - Django 2

• views.py contiene la lógica de la aplicación. Cada vista recibe una petición HTTP, la procesa y devuelve una respuesta.

Se va a comenzar por el diseño del esquema de datos del blog definiendo los modelos. Un modelo es una clase Python que hereda de django.db. models.Model, en la que cada atributo representa un campo de base de datos. Por cada uno de los modelos que se ha definido en el fichero models.py Django creará una tabla en la base de datos. A través de estos modelos, Django ofrece una API que permite realizar acciones sobre objetos de la base de datos de manera sencilla.

Para comenzar, se va a definir un modelo Post. Para ello se debe añadir las siguientes líneas en el fichero models.py de la aplicación blog:

Este es el modelo de datos para los artículos del blog. Los campos que se acaban de definir en el modelo son los siguientes:

• title es un campo que contiene el título del artículo y es de tipo CharField, lo que se traduce en una columna de tipo VARCHAR en la base de datos.

• slug es un campo utilizado para la generación de la URL para el artículo. Es una cadena de texto que puede estar formada por letras, números, guiones medios y/o bajos. Se utilizará este campo para construir URLs amigables y aptas para el SEO del sitio web. Se ha incluido el parámetro unique_for_date a este campo para poder añadir también a la URL la fecha de publicación del artículo. De este modo, Django prevendrá de tener múltiples artículos con el mismo slug para la misma fecha.

• author es una clave foránea que define una relación uno a muchos. De esta forma se indica a Django que un artículo está escrito por un usuario y que, a su vez, un usuario puede ser autor de muchos artículos. Django creará esta relación en la base de datos utilizando la clave primaria del modelo al que se hace referencia, en este caso, el modelo User del sistema de autenticación del framework. El parámetro on_delete especifica el comportamiento que debe tener el artículo cuando el objeto referenciado es eliminado. Esto no es específico de Django sino de la base de datos. Si se usa el valor CASCADE, al eliminar un autor se eliminarán también todos los artículos del blog asociados a este. Para el resto de opciones disponibles puede encontrar más información en https://docs.djangoproject.com/en/2.0/ref/models/fields/#django.db.models.ForeignKey.on_delete. Para especificar el nombre de la relación inversa (de User a Post), se utiliza el parámetro related_name. Esto nos permitirá acceder de manera sencilla a los objetos desde el modelo User.

• body contiene el cuerpo del artículo. Este campo es de tipo texto, el cual se convierte en una columna TEXT en lenguaje SQL de base de datos.

• publish es un campo de tipo fecha y hora que indica el momento de publicación del artículo. Por defecto, se usa el valor now del módulo timezone de Django. Este devuelve el momento actual según el huso horario en que se haya definido nuestro proyecto.

• created, al igual que publish, es un campo de tipo fecha y hora, pero que indica el momento de creación del artículo. Haciendo uso de auto_now_add, el valor se guardará automáticamente en la creación del objeto sin tener que especificarlo de forma explícita.

• updated es también un campo de fecha y hora. Como su nombre indica, muestra el momento del último cambio que sufrió el objeto. Para ello, se emplea auto_now, que actualizará automáticamente este valor.

• status es un campo tipo texto que contendrá los estados en los que puede estar el artículo. Haciendo uso del parámetro choices se limita el valor de status a una lista finita de valores.

Django ofrece una amplia variedad de tipos de campos para construir los modelos. En https://docs.djangoproject.com/en/2.0/ref/models/fields/se puede encontrar una lista completa de todos los que hay disponibles.

La clase Meta dentro del modelo define metadatos del propio modelo. En este caso se indica a Django que, por defecto, cuando se realice una consulta sobre este modelo en base de datos, ordene los resultados por el campo publish en orden descendente. Esto último, se especifica con el prefijo menos. De este modo, los artículos más recientes aparecerán primero.

El método __str__() es la representación legible del objeto. Django utiliza este método en múltiples lugares, entre otros, el sitio de administración.

Si ha usado Python 2.X, tenga en cuenta que en Python 3 todas las cadenas de texto son consideradas Unicode y, por tanto, solo se utiliza el método __str__(). El método __unicode__() está obsoleto.

Para que Django tenga constancia de la aplicación y poder realizar operaciones en ella, como crear las tablas de los modelos en base de datos, es necesario activarla. Para ello, se necesita abrir el fichero settings.py e incluir blog.apps.BlogConfig en la lista INSTALLED_APPS:

La clase BlogConfig es la aplicación de configuración. Al añadirla al setting INSTALLED_APPS Django tiene constancia de la aplicación y es capaz de cargar los modelos de datos que se defina en la misma.

Una vez creados los modelos de datos del blog, se necesita una tabla de base de datos para gestionarlos. Django incorpora un sistema de migraciones capaz de gestionar los cambios realizados en los modelos y aplicarlos sobre la base de datos. El comando migrate aplica las migraciones de todas las aplicaciones que se encuentren definidas en la variable INSTALLED_APPS, de modo que sincroniza las tablas de la base de datos con la definición de los modelos.

Lo primero que hay que hacer es crear una migración inicial para el modelo Post. Para ello, se debe ejecutar el siguiente comando:

Para el que se debería obtener la siguiente salida:

Django acaba de crear el fichero 0001_initial.py dentro del directorio migrations de la aplicación blog. Si se mira el contenido del fichero, se puede ver cómo una migración define dependencias entre migraciones y operaciones para realizar en la base de datos. Esto permite la sincronización que se mencionó antes entre la base de datos y el modelo.

A continuación, se describe el código SQL que Django ejecutará en la base de datos para crear la tabla del modelo. El comando sqlmigrate recibe el nombre de la migración y devuelve las sentencias SQL correspondientes sin llegar a ejecutarse. Utilice el siguiente comando para revisar la salida SQL de la migración anterior:

La salida debe tener el siguiente aspecto:

La salida dependerá del tipo de base de datos que se utilice. Esta ha sido generada para SQLite. Tal como se puede apreciar en el código SQL, Django genera un nombre de tabla combinando el nombre de la aplicación junto con el nombre del modelo (blog_post). Este comportamiento se puede modificar con el atributo db_table en la clase Meta del modelo. Django también crea por defecto una clave primaria por cada modelo. El campo que utiliza como clave primaria es la columna id de tipo entero con incremento automático. Django también permite modificar la clave primaria utilizando el parámetro primary_key=True en uno de los campos del modelo.