Antonio Melé - Django 2

Para realizar consultas sobre métodos de búsqueda de campos, se utilizan dos guiones bajos, por ejemplo, publish__year. Sin embargo, la misma notación se utiliza para acceder a campos de modelos relacionados, como author__username.

Se pueden excluir resultados del QuerySet a través del método exclude() del gestor. Por ejemplo, se pueden recuperar todos los posts publicados en 2017 cuyos títulos no empiezan por “ Why ”:

Los resultados se pueden ordenar con los campos a través del método order_by() del gestor. Por ejemplo, si quisiera obtener los artículos ordenados por el campo title, los obtendría con:

El comportamiento por defecto es en orden ascendente. Si lo quisiera descendente, utilizaría el prefijo negativo del siguiente modo:

Si quiere eliminar un objeto puede hacerlo con el método delete() del mismo:

Eliminar objetos provocará también la eliminación de objetos cuyas relaciones a través de ForeignKey estén definidas con el campo on_delete con valor CASCADE.

Ya ha visto que se pueden concatenar tantos filtros a un QuerySet como quiera, y que la base de datos no procesará la acción hasta que el QuerySet sea evaluado. Estos se evalúan en las siguientes situaciones:

• La primera vez que se itere sobre ellos.

• Cuando accedemos a un elemento/s por posición, por ejemplo, Post.objects.all()[:3].

• Cuando los seleccionamos o guardamos en caché.

• Cuando los invocamos con repr() o len().

• Cuando instanciamos una lista sobre ellos.

• Cuando realizamos una operación lógica como bool(), or, and, o if con ellos.

Ya mencionamos que objects es el gestor por defecto de cualquier modelo para recuperar objetos de la base de datos. Sin embargo, también se pueden definir gestores personalizados para los modelos. Se va a crear un gestor que recupere todos los artículos con el estado published.

Existen dos maneras de añadir gestores a los modelos: añadiendo métodos a los gestores ya existentes o modificando el gestor por defecto de QuerySets. La primera proporciona un método al API del QuerySet como Post.objects. my_manager() y, la segunda, como Post.my_manager.all(). En este caso, el gestor permitirá recuperar los artículos usando Post.published.all().

Para ello editamos el fichero models.py de la aplicación blog para incluir el nuevo gestor:

El método get_queryset() de un gestor devuelve el QuerySet ejecutado. Modificamos este método para incluir el filtrado al final del QuerySet. Se ha definido el gestor personalizado y añadido al modelo Post. Con esto ya puede utilizarlo para realizar consultas.

Se va a arrancar una consola de desarrollo con el siguiente comando:

Ahora, para recuperar todos los artículos publicados cuyo título empieza por Who, se utiliza la siguiente sentencia:

Se ha visto cómo se usa el ORM de Django. A continuación, se elaboran vistas en la aplicación del blog. Una vista de Django es una función Python que recibe una solicitud web y devuelve una respuesta web. Toda la lógica de procesamiento se encuentra dentro de la vista.

Lo primero que se va a hacer es crear las vistas de la aplicación, después se definen los patrones de URL para cada una de ellas y, por último, se crean las plantillas de HTML para renderizar el contenido con los datos de la vista. Cada vista renderiza una plantilla que se completa con datos de variables. Esta renderización se devuelve en una respuesta HTTP.

Se empieza con la elaboración de una vista que muestre el listado de artículos disponibles. Para ello se edita el fichero views.py de la aplicación blog con el siguiente código:

Acaba de crear su primera vista de Django, post_list, que recupera un objeto request como único parámetro. Este parámetro es obligatorio para todas las vistas y se recibirá siempre como primer argumento. En esta vista se recuperan todos los artículos con el estado published utilizando el gestor published creado anteriormente.

Por último, se hace uso del atajo render() que ofrece Django. Con él se renderizar la lista de artículos con la plantilla proporcionada como parámetro. Esta función recoge el objeto request, la ruta relativa de la plantilla y el contexto de variables para su correcta renderización, devolviendo un objeto HttpResponse con el texto renderizado (habitualmente HTML). Es necesario pasar el objeto request para que cualquiera de las variables definidas por los procesadores de contexto también sea accesible por la plantilla. Los procesadores de contexto de las plantillas son funciones que inicializan variables en el contexto. Este tema se describe detalladamente en el capítulo 3, Extensiones para el blog .

El paso siguiente es crear una segunda vista que muestre información de un artículo. Para ello hay que añadir el siguiente código al fichero views.py:

Esta es la vista detallada de un artículo. Esta vista toma los parámetros year, month, day y post para recuperar un artículo publicado con dicho slug y fecha. Hay que mencionar que durante la creación del modelo Post, se incluyó el parámetro unique_for_date en el campo slug. De este modo asegurará la singularidad de un slug para un día dado y, por tanto, la posibilidad de recuperar un único elemento dado un slug y una fecha. En la vista detallada se usa el atajo get_object_or_404() de Django para recuperar el artículo. Esta función devuelve un objeto que coincide con los datos proporcionados o lanza una excepción HTTP 404 (no encontrado) en caso de no hallarlo. Por último, se llama a la función render() para renderizar la información del artículo a través de una plantilla.