Modelos¶

Django básico

Como hemos visto en las características de Django existe un ORM que vincula tablas de la base de datos con objetos de Python.

Un modelo es simplemente una clase de Python que hereda características definidas (en otras clases) del propio framework de Django.

Se trata de una abstracción del modelo de datos que permite trabajar a más alto nivel. En teoría¹ podríamos cambiar el sistema gestor de base de datos que hay debajo y todo seguiría funcionando de la misma manera.

Creando modelos¶

Un modelo no es más que una clase Python que «suele» vivir en el fichero models.py de una aplicación Django.

Veamos un ejemplo en el que creamos un modelo Post de nuestro «blog» dentro de una aplicación llamada posts:

from django.db import models#(1)!


class Post(models.Model):#(2)!
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256)
    content = models.TextField()

    def __str__(self):#(3)!
        return self.title

1. Necesitamos importar el módulo models que nos dará aquellas funcionalidades necesarias para implementar nuestros modelos.
2. • La clase debe heredar de models.Model para que se convierta en un modelo válido.
   • En este caso se creará una tabla en la base de datos con el nombre posts_post (app_class).
3. Es muy recomendable definir el método __str__()

Existe una correspondencia entre el modelo de datos (clase) definido en Django y la tabla creada en la base de datos. Para el caso anterior se creará la tabla posts_post (app_model).

Campos¶

Los campos de un modelo no son más que atributos de clase.

Dentro del módulo django.db.models disponemos de una gran cantidad de tipos de campos. A continuación se muestra una tabla completa con los tipos de campos existentes en Django:

1. Tamaño máximo permitido (en bytes).
2. • Número máximo de caracteres que se pueden almacenar en la base de datos.
   • Es obligatorio para todos los sistemas gestores de bases de datos, salvo para PostgreSQL y SQLite.
3. • Puesto a True hace que el campo se actualice a la fecha actual cuando se crea el objeto.
   • No es obligatorio. Sólo usarlo en los casos en los que sea necesario.
4. • Puesto a True hace que el campo se actualice a la fecha actual cada vez que se guarda el objeto.
   • No es obligatorio. Sólo usarlo en los casos en los que sea necesario.
5. • Puesto a True hace que el campo se actualice a la fecha/hora actual cuando se crea el objeto.
   • No es obligatorio. Sólo usarlo en los casos en los que sea necesario.
6. • Puesto a True hace que el campo se actualice a la fecha/hora actual cada vez que se guarda el objeto.
   • No es obligatorio. Sólo usarlo en los casos en los que sea necesario.
7. • Número máximo de dígitos permitidos en el número.
   • Incluye tanto los dígitos a la izquierda de la «coma» como los dígitos a la derecha de la «coma».
8. • Número de cifras decimales para almacenar el número.
   • Por ejemplo para almacenar números hasta 999.99 usaríamos:
     • max_digits=5
     • decimal_places=2
9. Número máximo de caracteres que se pueden almacenar en la base de datos.
10. Ruta en la que almacenar el archivo una vez que se suba.
11. Objeto de almacenamiento.
12. Número máximo de caracteres que se pueden almacenar en la base de datos.
13. Ruta de sistema desde la que se extraen las opciones del campo.
14. Expresión regular para filtrar nombres de fichero.
15. • Si es True se listará recursivamente todo el contenido de la ruta indicada.
    • Por defecto es False.
16. • Si es True permite el listado de ficheros.
    • Por defecto es True.
17. • Si es True permite el listado de directorios.
    • Por defecto es False.
18. Número máximo de caracteres que se pueden almacenar en la base de datos.
19. Objeto de tipo Expression para el cálculo del campo.
20. Instancia de campo de modelo que define el tipo de datos del campo.
21. • Si es True la columna en la base de datos será almacenada como real.
    • En otro caso la columna actuará como una columna virtual.
22. Limita la entrada al protocolo especificado.
23. Desempaqueta direcciones IPv4.
24. Ruta en la que almacenar el archivo una vez que se suba.
25. Nombre de un campo de modelo que contendrá el alto de la imagen.
26. Nombre de un campo de modelo que contendrá el ancho de la imagen.
27. Número máximo de caracteres que se pueden almacenar en la base de datos.
28. Una subclase de JSONEncoder para serializar los tipos de datos no soportados por el serializador JSON.
29. Una subclase de JSONDecoder para deserializar la entrada.
30. Número máximo de caracteres que se pueden almacenar en la base de datos.
31. • Puesto a True hace que el campo se actualice a la hora actual cuando se crea el objeto.
    • No es obligatorio. Sólo usarlo en los casos en los que sea necesario.
32. • Puesto a True hace que el campo se actualice a la hora actual cada vez que se guarda el objeto.
    • No es obligatorio. Sólo usarlo en los casos en los que sea necesario.
33. Número máximo de caracteres que se pueden almacenar en la base de datos.

Parámetro requerido.

Tamaño de enteros¶

Veamos a continuación una tabla resumen del tamaño de los distintos campos enteros existentes en los modelos de Django:

Migraciones¶

Una migración es un fichero de código Python que contiene las instrucciones a ejecutar sobre la correspondiente tabla de la base de datos en función de los cambios realizados en el modelo.

Tras cualquier modificación del fichero models.py es necesario:

Crear migración Aplicar migración

Para crear las migraciones ejecutamos el comando:

venv uv  

$ ./manage.py makemigrations #(1)!
Migrations for 'posts':
  posts/migrations/0001_initial.py
    + Create model Post

1. Admite la posibilidad de indicar una aplicación como argumento para crear únicamente las migraciones de dicha aplicación.

$ uv run manage.py makemigrations #(1)!
Migrations for 'posts':
  posts/migrations/0001_initial.py
    + Create model Post

1. Admite la posibilidad de indicar una aplicación como argumento para crear únicamente las migraciones de dicha aplicación.

justfile

Consulta la receta makemigrations para incluirla en tu justfile.

Para aplicar las migraciones ejecutamos el comando:

venv uv  

$ ./manage.py migrate #(1)!
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0001_initial... OK

1. Admite la posibilidad de indicar una aplicación como argumento para aplicar únicamente las migraciones de dicha aplicación.

$ uv run manage.py migrate #(1)!
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0001_initial... OK

1. Admite la posibilidad de indicar una aplicación como argumento para aplicar únicamente las migraciones de dicha aplicación.

justfile

Consulta la receta migrate para incluirla en tu justfile.

Ficheros de migración¶

Las migraciones se almacenan en la carpeta migrations dentro de la correspondiente aplicación.

flowchart LR
    models[models.py]
    subgraph Migrations
        makemigrations["<tt>./manage.py makemigrations</tt>"]
        makemigrations --> migrate["<tt>./manage.py migrate</tt>"]
    end
    models --> makemigrations
    makemigrations -.-> migrations[migrations/0001_migration.py]
    migrate --> Database

Veamos la migración inicial sobre el modelo Posts definido previamente en nuestro «blog»:

# Generated by Django 5.2.6 on 2025-10-01 09:11

from django.db import migrations, models


class Migration(migrations.Migration):

    initial = True

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Post',
            fields=[
                ('id', models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('title', models.CharField(max_length=256)),
                ('slug', models.SlugField(max_length=256)),
                ('content', models.TextField()),
            ],
        ),
    ]

Como puede observarse en el fragmento de código anterior no aparece ninguna sentencia SQL. Lo que encontramos es código Python con indicaciones de alto nivel que serán «traducidas» a SQL para su aplicación sobre la base de datos.

Registro de migraciones¶

Django nos ofrece la posibilidad de comprobar el registro de migraciones:

$ ./manage.py showmigrations #(1)!
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [X] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
 [X] 0010_alter_group_name_max_length
 [X] 0011_update_proxy_permissions
 [X] 0012_alter_user_first_name_max_length
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
posts
 [X] 0001_initial
sessions
 [X] 0001_initial

$ uv run manage.py showmigrations #(1)!
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [X] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
 [X] 0010_alter_group_name_max_length
 [X] 0011_update_proxy_permissions
 [X] 0012_alter_user_first_name_max_length
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
posts
 [X] 0001_initial
sessions
 [X] 0001_initial

Aquellas migraciones marcadas con significa que ya se han aplicado.

Revertir migraciones¶

Para plantear un escenario inicial, vamos por ejemplo a hacer un pequeño cambio sobre el modelo Post ampliando el tamaño de los campos title y slug:

from django.db import models


class Post(models.Model):
    title = models.CharField(max_length=300)
    slug = models.SlugField(max_length=300)
    content = models.TextField()

    def __str__(self):
        return self.title

Ahora creamos la migración:

$ ./manage.py makemigrations posts
Migrations for 'posts':
  posts/migrations/0002_alter_post_slug_alter_post_title.py
    ~ Alter field slug on post
    ~ Alter field title on post

$ uv run manage.py makemigrations posts
Migrations for 'posts':
  posts/migrations/0002_alter_post_slug_alter_post_title.py
    ~ Alter field slug on post
    ~ Alter field title on post

Y a continuación aplicamos la migración:

$ ./manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0002_alter_post_slug_alter_post_title... OK    

$ uv run manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0002_alter_post_slug_alter_post_title... OK    

Si visualizamos el registro de migraciones veremos que esta última migración ya se ha aplicado:

$ ./manage.py showmigrations posts
posts
 [X] 0001_initial
 [X] 0002_alter_post_slug_alter_post_title

$ uv run manage.py showmigrations posts
posts
 [X] 0001_initial
 [X] 0002_alter_post_slug_alter_post_title

En este punto podríamos querer revertir («rollback») la última migración. Para ello simplemente migramos al punto de la historia que necesitemos:

$ ./manage.py migrate posts 0001#(1)!
Operations to perform:
  Target specific migration: 0001_initial, from posts
Running migrations:
  Rendering model states... DONE
  Unapplying posts.0002_alter_post_slug_alter_post_title... OK

$ uv run manage.py showmigrations posts #(2)!
posts
 [X] 0001_initial
 [ ] 0002_alter_post_slug_alter_post_title

$ uv run manage.py migrate posts 0001#(1)!
Operations to perform:
  Target specific migration: 0001_initial, from posts
Running migrations:
  Rendering model states... DONE
  Unapplying posts.0002_alter_post_slug_alter_post_title... OK

$ uv run manage.py showmigrations posts #(2)!
posts
 [X] 0001_initial
 [ ] 0002_alter_post_slug_alter_post_title

La migración se ha revertido correctamente. Si quisiéramos eliminar del registro la migración 0002 bastaría con eliminar el fichero:

$ rm posts/migrations/0002_alter_post_slug_alter_post_title.py

Ahora si volvemos a comprobar el registro de migraciones, vemos que todo está como esperaríamos:

$ ./manage.py showmigrations posts
posts
 [X] 0001_initial

$ uv run manage.py showmigrations posts
posts
 [X] 0001_initial

Por último, para volver a dejar todo «como estaba», modificamos de nuevo el tamaño de los campos como se había especificado inicialmente:

from django.db import models


class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256)
    content = models.TextField()

    def __str__(self):
        return self.title

Migraciones manuales¶

Django avanzado

Hay ocasiones en las que necesitamos crear migraciones manuales (migraciones de datos) para resolver determinados escenarios durante la vida de un proyecto Django.

Vamos a suponer por ejemplo un escenario en el que partimos de un modelo de «post» como el siguiente:

from django.db import models


class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256)
    content = models.TextField()

    def __str__(self):
        return self.title

Para disponer de datos iniciales en la base de datos, descargamos este fichero posts.json y cargamos las «fixtures»:

$ ./manage.py loaddata posts #(1)!
Installed 5 object(s) from 1 fixture(s)

$ uv run manage.py loaddata posts #(1)!
Installed 5 object(s) from 1 fixture(s)

Desde «arriba» nos dicen que ahora los «posts» pasarán a ser identificados unívocamente por un campo pid alfanumérico. Por tanto nos vemos obligados a modificar el modelo y añadir dicho atributo:

from django.db import models


class Post(models.Model):
    pid = models.CharField(unique=True)
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256)
    content = models.TextField()

    def __str__(self):
        return self.title

Veamos lo que ocurre si intentamos crear la migración:

$ ./manage.py makemigrations posts
It is impossible to add a non-nullable field 'pid' to post without specifying a default. This is because the database needs something to populate existing rows.
Please select a fix:
1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
2) Quit and manually define a default value in models.py.
Select an option: 2

$ uv run manage.py makemigrations posts
It is impossible to add a non-nullable field 'pid' to post without specifying a default. This is because the database needs something to populate existing rows.
Please select a fix:
1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
2) Quit and manually define a default value in models.py.
Select an option: 2

Lo que está ocurriendo aquí es que ya existen «posts» en la correspondiente tabla de la base de datos y Django no puede añadir la columna pid sin asignar un valor para las filas existentes. Ni siquiera se le podría dar como valor inicial la cadena vacía porque los valores deben ser únicos.

Por tanto aquí vamos a seguir otra estrategia para resolver este problema:

1. Añadir el campo pid como opcional.
2. Implementar una migración manual para rellenar los datos de pid.
3. Modificar el campo pid para que sea requerido y único.

Añadir campo opcional¶

Modificamos la definición del atributo pid para hacerlo opcional:

from django.db import models


class Post(models.Model):
    pid = models.CharField(max_length=256, blank=True)
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256)
    content = models.TextField()

    def __str__(self):
        return self.title

Creamos y aplicamos la migración correspondiente:

$ ./manage.py makemigrations posts
Migrations for 'posts':
  posts/migrations/0002_post_pid.py
    + Add field pid to post

$ ./manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0002_post_pid... OK

$ uv run manage.py makemigrations posts
Migrations for 'posts':
  posts/migrations/0002_post_pid.py
    + Add field pid to post

$ uv run manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0002_post_pid... OK

Rellenar datos¶

Ahora estamos en disposición de crear una migración manual para rellenar los datos del campo pid. Para ello hacemos lo siguiente:

$ ./manage.py makemigrations --empty posts
Migrations for 'posts':
  posts/migrations/0003_auto_20260411_0901.py

$ uv run manage.py makemigrations --empty posts
Migrations for 'posts':
  posts/migrations/0003_auto_20260411_0901.py

Editamos la migración creada para añadir el código necesario:

# Generated by Django 5.2.6 on 2026-04-11 09:01

import hashlib

from django.db import migrations


def fill_pid(apps, schema_editor):#(1)!
    Post = apps.get_model('posts', 'Post')#(2)!
    for post in Post.objects.all():#(3)!
        post.pid = hashlib.md5(post.title.encode()).hexdigest()#(4)!
        post.save()#(5)!


def undo_fill_pid(apps, schema_editor):#(6)!
    Post = apps.get_model('posts', 'Post')#(7)!
    for post in Post.objects.all():#(8)!
        post.pid = ''#(9)!
        post.save()#(10)!


class Migration(migrations.Migration):#(11)!
    dependencies = [#(12)!
        ('posts', '0002_post_pid'),
    ]

    operations = [#(13)!
        migrations.RunPython(fill_pid, undo_fill_pid),#(14)!
    ]

1. Cada función a aplicar en la migración manual recibe dos parámetros:
   • apps que contiene un registro de todas las versiones históricas de los modelos.
   • schema_editor que permite hacer cambios manuales en la base de datos.
2. Obtenemos el modelo Post de la aplicación posts (en el momento histórico actual).
3. Recorremos todos los «posts» existentes actualmente.
4. Aplicamos un hash md5 al título para obtener el nuevo identificador de post.
5. Guardamos los cambios en la base de datos.
6. Cada función a aplicar en la migración manual recibe dos parámetros:
   • apps que contiene un registro de todas las versiones históricas de los modelos.
   • schema_editor que permite hacer cambios manuales en la base de datos.
7. Obtenemos el modelo Post de la aplicación posts (en el momento histórico actual).
8. Recorremos todos los «posts» existentes actualmente.
9. Reseteamos el identificador de post como cadena vacía.
10. Guardamos los cambios en la base de datos.
11. Esta clase es la migración en sí.
12. Se establece la dependencia de esta migración justo con la anterior.
13. Esta variable lleva un registro de las operaciones a realizar en la migración.
14. Ejecutamos código Python, concretamente dos funciones:
    • La función fill_pid() es el camino «hacia adelante» en la migración.
    • La función undo_fill_pid() es el camino «hacia atrás» en la migración.

Una vez creada esta migración, procedemos a aplicarla:

$ ./manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0003_auto_20260411_0901... OK

$ uv run manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0003_auto_20260411_0901... OK

Si echamos un vistazo al contenido de la base de datos podremos observar que el campo pid de todos los «posts» se ha rellenado correctamente con el valor esperado:

>>> for post in Post.objects.all():
...     print(f'{post.title:20s} | {post.pid}')
...
Small Changes        | 5fba4065cce227573533119c08fd0cfb
Learning Takes Time  | f639832738dd1b495c00ac0323de6577
Thinking in Code     | 853b27a8c1fc995e23b6ffdf0ec16fe6
Useful Mistakes      | 9e92b3e7603272a0e16fe152712a92cd
Curiosity            | 45ac168eaee7da65d269036c7b5b39e1

Modificar campo único¶

Dado que ahora el campo pid tiene contenido para todos los objetos «post» de la base de datos, podemos modificarlo como valor único sin riesgo a tener ningún tipo de problema:

from django.db import models


class Post(models.Model):
    pid = models.CharField(max_length=256, unique=True)
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256)
    content = models.TextField()

    def __str__(self):
        return self.title

Creamos y aplicamos la migración correspondiente:

$ ./manage.py makemigrations posts
Migrations for 'posts':
  posts/migrations/0004_alter_post_pid.py
    ~ Alter field pid on post

$ ./manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0004_alter_post_pid... OK

$ uv run manage.py makemigrations posts
Migrations for 'posts':
  posts/migrations/0004_alter_post_pid.py
    ~ Alter field pid on post

$ uv run manage.py migrate posts
Operations to perform:
  Apply all migrations: posts
Running migrations:
  Applying posts.0004_alter_post_pid... OK

Ahora efectivamente ya hemos completado este proceso de migración manual que conlleva varios pasos pero que asegura una consistencia en la base de datos con respecto al modelo que estamos implementado.

Base de datos¶

La configuración de la base de datos del proyecto se encuentra en la variable DATABASES del fichero settings.py y (por defecto) tiene este aspecto:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

Podemos ver que se trata de un diccionario con una clave default lo que nos hace pensar que podemos definir configuraciones alternativas para la base de datos.

En esta configuración (por defecto) tenemos un motor de base de datos SQLite que almacenará la información en un fichero db.sqlite3 dentro de la carpeta base³ (raíz) del proyecto.

Clave primaria¶

Siempre que creemos un nuevo modelo y no definamos una clave primaria, Django generará automáticamente un campo id de tipo BigAutoField (entero largo autoincremental) que se materializa en la base de datos mediante:

"id" integer NOT NULL PRIMARY KEY AUTOINCREMENT

En el caso de que efectivamente queramos crear una clave primaria propia, basta con indicarlo a la hora de escribir nuestro modelo. Supongamos un ejemplo donde el «slug» de un «post» (blog) fuera la clave primaria:

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, primary_key=True)
    content = models.TextField()

Valores únicos¶

Hay escenarios en los que necesitamos que los valores de un determinado campo no se repitan, o dicho de otra forma, que sea únicos. En este sentido Django nos permite especificarlo mediante un parámetro en el campo correspondiente.

Siguiendo con el ejemplo anterior de un «post», quizás nos puede interesar que slug sea único. Para ello simplemente hacemos:

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, unique=True)
    content = models.TextField()

Valores únicos juntos¶

Django intermedio

Aunque quizás no sea del todo realista, supongamos un ejemplo en el que no pueden haber dos «posts» con el mismo título y «slug».

Para modelar esto haremos uso del atributo unique_together que ofrece Django:

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, unique=True)
    content = models.TextField()

    class Meta:#(1)!
        unique_together = ['title', 'slug']

1. • La clase interior Meta permite indicarle a Django ciertas opciones para un modelo.
   • Por una cuestión de «estilo» se suele escribir justo debajo de los atributos del modelo.

Campos opcionales¶

Hay ocasiones en las que necesitamos que ciertos campos del modelo puedan quedar vacíos, es lo que conocemos como campos opcionales. La cuestión aquí es que la definición de «vacío» en la base de datos no siempre es tan evidente.

Lo más habitual es entender que NULL sea el valor «vacío» en una base de datos SQL, pero Django distingue el caso de los campos basados en «string», ya que estos podrían admitir dos posibles valores para «vacío»: Uno es NULL y otro es la cadena vacía.

Por otro lado está el tema de las validaciones que hace Django a la hora de introducir datos en nuestros modelos desde la interfaz administrativa. En este sentido se puede establecer que un campo no es requerido, por lo que podría quedar «vacío» a la hora de rellenarlo.

Con todo esto, Django establece dos parámetros que tienen que ver con este escenario de campos «vacíos»:

• null=True: Indica que un valor «vacío» se almacenará en la base de datos como NULL.
• blank=True: Indica que la validación Django permitirá la entrada de un valor «vacío».

Combinando estos dos parámetros podemos definir campos opcionales para nuestro modelo. Veamos una tabla resumen:

ORM¶

Como ya se introdujo en las características de Django el ORM (Object-Relational Mapper) es la herramienta que permite interactuar con bases de datos usando objetos y clases de Python en lugar de escribir directamente consultas SQL.

Shell¶

Django nos permite abrir una «shell» (intérprete interactivo de Python) con las configuraciones del proyecto ya cargadas:

$ ./manage.py shell
7 objects imported automatically (use -v 2 for details).

Python 3.13.2 (main, Feb 12 2025, 14:59:08) [Clang 19.1.6 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

$ uv run manage.py shell
7 objects imported automatically (use -v 2 for details).

Python 3.13.2 (main, Feb 12 2025, 14:59:08) [Clang 19.1.6 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

Como puede verse en el fragmento de código anterior, Django importa automáticamente(1) distintos objetos de nuestro proyecto. En el caso concreto de nuestro «blog» se han importado los siguientes:

1. Para mostrar los «import» automáticos se puede añadir la opción: manage.py shell -v2

from posts.models import Post
from django.contrib.sessions.models import Session
from django.contrib.contenttypes.models import ContentType
from django.contrib.auth.models import User, Group, Permission
from django.contrib.admin.models import LogEntry

$ uv add --dev ipython

Creando objetos¶

Para crear un nuevo objeto (y almacenarlo en la base de datos) mediante el ORM de Django, disponemos de dos aproximaciones:

>>> from posts.models import Post#(1)!

>>> p = Post(#(2)!
...     title='Check out the new Django version',
...     slug='check-out-the-new-django-version',
...     content='Awesome features of the last release of Django',
... )
>>> p.save()#(3)!

>>> from posts.models import Post#(1)!

>>> p = Post.objects.create(#(2)!
...     title='Check out the new Django version',
...     slug='check-out-the-new-django-version',
...     content='Awesome features of the last release of Django',
... )

>>> Post.objects.create(
...     title='Understanding URL routing in Django',
...     slug='understanding-url-routing-in-django',
...     content='Learn how Django URL patterns work and how to organize routes for scalable applications.',
... )

>>> Post.objects.create(
...     title='Working with function-based views in Django',
...     slug='working-with-function-based-views-in-django',
...     content='Learn how to handle requests and responses using function-based views in Django applications.',
... )

>>> Post.objects.create(
...     title='Mastering Django templates',
...     slug='mastering-django-templates',
...     content='Understand template inheritance, context variables, and best practices for clean frontend rendering.',
... )

>>> Post.objects.create(
...     title='Working with forms in Django',
...     slug='working-with-forms-in-django',
...     content='Learn how to create, validate, and process forms using Django forms and ModelForms.',
... )

Shell de base de datos¶

Django nos permite abrir una «shell» de base de datos (interfaz de comandos del sistema gestor) con las configuraciones del proyecto ya cargadas.

Suponiendo que estamos usando la configuración por defecto de SQLite, primero debemos tener instalado el cliente de SQLite en nuestro sistema:

> winget install -e --id SQLite.SQLite#(1)!

$ brew install sqlite #(1)!

$ sudo apt-get install sqlite3

Podemos abrir una «shell» de base de datos con el comando:

$ ./manage.py dbshell
SQLite version 3.43.2 2023-10-10 13:08:14
Enter ".help" for usage hints.
sqlite>

$ uv run manage.py dbshell
SQLite version 3.43.2 2023-10-10 13:08:14
Enter ".help" for usage hints.
sqlite>

Podemos comprobar con una sencilla consulta SQL que el objeto se ha creado correctamente en la base de datos:

sqlite> .mode line
sqlite> SELECT * FROM posts_post;
     id = 1
  title = Check out the new Django version
   slug = check-out-the-new-django-version
content = Awesome features of the last release of Django

$ just dbcmd 'SELECT * FROM posts_post'

Guardando objetos¶

El método save() nos permite guardar los cambios realizados en una instancia de un modelo. Por tanto podemos modificar los valores de sus campos y reflejarlos en la base de datos.

Supongamos por ejemplo que p es un objeto de tipo Post y queremos modificar su título:

>>> p.title = 'This is a better title'
>>> p.save()

Recuperando objetos¶

Todos los objetos¶

La primera aproximación a la consulta de datos será obtener todos los objetos de un determinado modelo.

Partiendo del ejemplo con el modelo Post podríamos recuperar todos sus objetos con:

>>> from posts.models import Post

>>> Post.objects.all()#(1)!

1. • El atributo objects es el «manager» por defecto.
   • El método all() devuelve un QuerySet (una especie de lista «perezosa» de objetos).

>>> qs = Post.objects.all()

>>> print(qs.query)
SELECT "posts_post"."id",
       "posts_post"."title",
       "posts_post"."slug",
       "posts_post"."content"
FROM "posts_post"

Ciertos objetos¶

Para recuperar determinados objetos que cumplan ciertas condiciones vamos a utilizar el método filter(). Se trata de un método que recipe como parámetro las condiciones a satisfacer por los objetos del modelo.

Supongamos un ejemplo en el que queremos recuperar todos aquellos «posts» cuyo título empiece por la letra A:

>>> from posts.models import Post

>>> Post.objects.filter(title__startswith='A')#(1)!

1. • El atributo objects es el «manager» por defecto.
   • El método filter() devuelve un QuerySet (una especie de lista «perezosa» de objetos).
   • startswith es un «field lookup». Existen muchos otros.

Un único objeto¶

La forma más «obvia» de recuperar un objeto de modelo es mediante su clave primaria.

En el siguiente ejemplo vamos a recuperar un «post» cuya clave primaria es 7:

>>> from posts.models import Post

>>> p = Post.objects.get(pk=7)#(1)!

1. Podríamos haber utilizado Post.objects.get(id=7) pero el hecho de usar pk es una buena práctica y nos «abstrae» del nombre concreto que tenga el campo de clave primaria en la tabla de la base de datos.

try:
    p = Post.objects.get(pk=-1)
except Post.DoesNotExist as err:
    print('Sorry the post you need does not exist')

Es posible que en cierta documentación de Django encuentres la siguiente «fórmula» para obtener un único objeto:

post = Post.objects.filter(pk=7).first()#(1)!

1. Utilizamos la función first().

Hay que diferenciar dos casos:

1. Si el «post» que buscamos existe, lo obtendremos en la variable post.
2. Si el «post» que buscamos no existe, obtendremos None (a diferencia de get() donde se lanza una excepción).

Excluyendo objetos¶

Hay escenarios en los que se necesita excluir ciertos objetos del total o de determinado consulta previa. Para estos casos Django proporciona el método exclude().

Supongamos un ejemplo en el que queremos obtener todos los «posts» cuyo título empiece por la letra A pero que no terminen por la letra z:

>>> from posts.models import Post

>>> Post.objects.filter(title__startswith='A').exclude(title__endswith='z')#(1)!

1. • El atributo objects es el «manager» por defecto.
   • El método filter() devuelve un QuerySet (una especie de lista «perezosa» de objetos).
   • startswith es un «field lookup». Existen muchos otros.
   • El método exclude() devuelve un QuerySet (una especie de lista «perezosa» de objetos).
   • endswith es un «field lookup». Existen muchos otros.

>>> Post.objects.filter(<selector>).exclude(<selector>).filter(<selector>) # ...

Selectores de consulta¶

Para construir consultas podemos hacer uso de los «field lookups» (selectores) de Django. Lo podemos ver como el contenido que aparecerá posteriormente en la cláusula WHERE de la sentencia SQL correspondiente.

La sintaxis para usar estos selectores es la siguiente:

<Model>.objects.filter(<field>__<lookup>)#(1)!

1. También funciona para get() y para exclude().

A continuación se muestran todos los selectores de consulta disponibles en Django:

1. • En SQLite ignora mayúsculas/minúsculas.
   • En PostgreSQL respeta mayúsculas/minúsculas.
2. • En SQLite ignora mayúsculas/minúsculas.
   • En PostgreSQL respeta mayúsculas/minúsculas.
3. • En SQLite ignora mayúsculas/minúsculas.
   • En PostgreSQL respeta mayúsculas/minúsculas.

Borrando objetos¶

Una vez que tenemos localizado el objeto que queremos borrar, es muy sencillo ya que simplemente tendremos que invocar al método delete():

>>> post.delete()#(1)!
(1, {'posts.Post': 1})

1. Devuelve una tupla con:
   Número total de objetos borrados.
   Diccionario con el tipo de objeto y el número de objetos borrados de cada tipo.

Este método también funciona para borrados en lote. Por ejemplo:

>>> Post.objects.all().delete()
(10, {'posts.Post': 10})

Contando objetos¶

Hay muchas ocasiones en las que resulta necesario obtener el número de objetos que tiene una determinada consulta. Para ello Django nos ofrece el método count().

Si queremos por ejemplo sacar el número total de «posts» que hay en nuestro «blog» podríamos escribir lo siguiente:

>>> from posts.models import Post

>>> Post.objects.count()#(1)!
10

1. También se puede aplicar sobre un filtro Post.objects.filter(title__contains='Test').count()

>>> len(Post.objects.all())
10

Comprobando existencia¶

No siempre buscamos contar el número de resultados sino que únicamente necesitamos saber si existen o no objetos para una determinada consulta. Es por ello que Django ofrece el método exists() que devuelve True o False.

Por ejemplo si queremos saber si existen «posts» que comienzan por la letra «A»:

>>> from posts.models import Post

>>> if Post.objects.filter(title__startswith='A').exists():
...     print('Hay posts que empiezan por la letra A')

Ordenando resultados¶

Es muy habitual querer ordenar el resultado de una consulta por uno o varios campos. Para ello Django nos ofrece la función order_by().

Supongamos por ejemplo que queremos ordenar el listado de «posts» por su título:

>>> from posts.models import Post

>>> Post.objects.order_by('title')#(1)!

1. • Podemos añadir más campos de ordenación simplemente añadiendo más argumentos.
   • Por ejemplo order_by('title', 'content') significa que si dos «posts» tienen el mismo título se ordenarán por su contenido.

Primeros y últimos¶

Django ofrece varias funciones para acceder a los primeros y últimos objetos de una consulta que cumplan ciertas condiciones:

>>> Post.objects.order_by('title').first()

>>> Post.objects.order_by('title').last()

>>> Post.objects.earliest('pk')

>>> Post.objects.latest('pk')

Actualizando objetos¶

Django proporciona el método update() para actualizar múltiples objetos a la vez.

Supongamos por ejemplo que queremos borrar el contenido de todos los «posts» de nuestro «blog». Para ello podemos utilizar esta aproximación:

>>> Post.objects.update(content='')#(1)!
10

1. • El método devuelve el número de objetos afectados.
   • Es posible indicar varios atributos a actualizar simultáneamente.
   • Obviamente también se puede utilizar sobre una operación de filtrado.

Refrescando objetos¶

Hay ocasiones en las que los valores de un objeto (de modelo) no están sincronizados con sus correspondientes en la base de datos. Para actualizar dichos atributos, Django ofrece el método refresh_from_db().

Por ejemplo un «post» que se actualiza en la base de datos pero no en memoria:

>>> from posts.models import Post

>>> post = Post.objects.get(slug='first-post')#(1)!

>>> post.content#(2)!
'First post'

>>> Post.objects.filter(slug='first-post').update(content='Updated content')#(3)!
1

>>> post.content#(4)!
'First post'

>>> post.refresh_from_db()#(5)!

>>> post.content#(6)!
'Updated content'

1. Recuperamos un determinado «post» de nuestro «blog».
2. Comprobamos su contenido.
3. Actualizamos su contenido (en la base de datos).
4. Comprobamos su contenido (en memoria) que no está sincronizado con la base de datos.
5. Refrescamos el objeto desde la base de datos.
6. Comprobamos que qhora su contenido (en memoria) sí coincide con el que tiene la base de datos.

En realidad la operación refresh_from_db() es la opuesta a save():

flowchart TD
    model@{ shape: div-rect, label: "Model instance" } --->|"<tt>save</tt>"| database@{ shape: cyl, label: "Database" }
    database --->|"<tt>refresh_from_db</tt>"| model

Tipos enumerados¶

Django avanzado

Django nos permite definir tipos enumerados que establecen un conjunto (normalmente pequeño) de posibles valores.

Un tipo enumerado se define por dos componentes: una etiqueta (nombre largo) y un valor (código corto). Lo que hace Django es almacenar en la base de datos únicamente el valor, mientras que la «etiqueta» se establece en la definición del campo.

Django ofrece dos variantes:

Tipos enumerados basados en cadenas de texto → Enumerados textuales.
Tipos enumerados basados en números enteros → Enumerados enteros.

Enumerados textuales¶

En este escenario se utiliza un campo CharField y se definen los posibles valores mediante el parámetro choices a través de una subclase de models.TextChoices.

Supongamos un ejemplo en el que queremos clasificar los «posts» del «blog» por categorías:

from django.db import models


class Post(models.Model):
    class Category(models.TextChoices):#(1)!
        SOCIETY = 'SOC', 'Society'#(2)!
        EDUCATION = 'EDU', 'Education'
        HEALTH = 'HLT', 'Health'
        CULTURE = 'CUL', 'Culture'
        TECH = 'TEC', 'Technology'

    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, unique=True)
    content = models.TextField()
    category = models.CharField(#(3)!
        max_length=3,#(4)!
        choices=Category,#(5)!
        default=Category.SOCIETY,#(6)!
    )

1. • Esta clase interior nos permite definir las distintas opciones.
   • Suele ser buena práctica darle el mismo nombre que al atributo que va a definir.
2. • Cada atributo de clase indica una opción en formato tupla: <COD_CORTO>, <NOMBRE_LARGO>
   • El código corto debería ser un string de pocos caracteres (longitud 1, 2, 3, ...)

   • Si no se especifica el nombre largo, Django lo infiere del propio código corto:

     SCIENCE_FICTION = 'SCI'#(1)!
     

     1. El nombre largo será 'Science Fiction' inferido desde SCIENCE_FICTION.

3. El campo se define como un CharField().

4. El tamaño máximo debe coincidir con la longitud del código corto.
5. Se definen las opciones con referencia a la clase interior.
6. No es obligatorio aunque sí recomendable definir un valor por defecto.

La clase interior Category es de tipo TextChoices y permite ciertas operaciones:

>>> Post.Category.choices
[('SOC', 'Society'), ('EDU', 'Education'), ('HLT', 'Health'), ('CUL', 'Culture'), ('TEC', 'Technology')]

>>> Post.Category.labels
['Society', 'Education', 'Health', 'Culture', 'Technology']

>>> Post.Category.values
['SOC', 'EDU', 'HLT', 'CUL', 'TEC']

>>> Post.Category.names
['SOCIETY', 'EDUCATION', 'HEALTH', 'CULTURE', 'TECH']

Veamos la forma de acceder a la categoría de un determinado «post»:

>>> from posts.models import Post
>>> post = Post.objects.first()

>>> post.category
'SOC'

>>> from posts.models import Post
>>> post = Post.objects.first()

>>> post.get_category_display()#(1)!
'Society'

Para comprobar el valor de un tipo enumerado debemos hacer uso de la clase interior. Veamos un ejemplo en el que queremos verificar si un determinado «post» es educativo:

if post.category == 'EDU':#(1)!
    # ...

from posts.models import Post

if post.category == Post.Category.EDUCATION:
    # ...

Para comprobar si el valor está dentro de un enumerado también debemos hacer uso de la clase interior. Veamos un ejemplo en el que queremos verificar si un determinado valor es una categoría de «post»:

if 'EDU' in ['SOC', 'EDU', 'HLT', 'CUL', 'TEC']:#(1)!
    # ...

from posts.models import Post

if 'EDU' in Post.Category:
    # ...

Enumerados enteros¶

En este escenario se utiliza un campo IntegerField y se definen los posibles valores mediante el parámetro choices a través de una subclase de models.IntegerChoices.

Supongamos un ejemplo en el que queremos valorar la calidad de los «posts» del «blog» en base a una escala predeterminada:

from django.db import models


class Post(models.Model):
    class Rating(models.IntegerChoices):#(1)!
        VERY_BAD = 1#(2)!
        BAD = 2
        AVERAGE = 3
        GOOD = 4
        EXCELLENT = 5

    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, unique=True)
    content = models.TextField()
    rating = models.IntegerField(#(3)!
        choices=Rating,#(4)!
        default=Rating.AVERAGE,#(5)!
    )

1. • Esta clase interior nos permite definir las distintas opciones.
   • Suele ser buena práctica darle el mismo nombre que al atributo que va a definir.
2. • Cada atributo de clase indica una opción en formato tupla: <COD_CORTO>, <NOMBRE_LARGO>
   • El código corto debería ser un entero.
   • Si no se especifica el nombre largo, Django lo infiere del propio código corto.
   • En este caso, la etiqueta sería 'Very Bad'
   • No es obligatorio que los valores sean correlativos.
3. • El campo se define como un IntegerField().
   • Aunque dependiendo del contexto se podría usar un PositiveSmallIntegerField().
4. Se definen las opciones con referencia a la clase interior.
5. No es obligatorio aunque sí recomendable definir un valor por defecto.

>>> from posts.models import Post

>>> post1 = Post.objects.first()
>>> post2 = Post.objects.last()

>>> post1.rating
3
>>> post2.rating
1

>>> post1.get_rating_display()
'Average'
>>> post2.get_rating_display()
'Very Bad'

>>> post1.rating > post2.rating
True

Claves ajenas¶

Django intermedio

Una de las mayores fortalezas de los Sistemas Gestores de Bases de Datos Relacionales RDBMS es la de poder «relacionar» entidades (modelos) mediante el uso de claves ajenas.

Django nos ofrece muchas funcionalidades en este sentido, que podemos agrupar en tres escenarios:

Relaciones uno a muchos → \(1:N\)
Relaciones uno a uno → \(1:1\)
Relaciones muchos a muchos → \(N:N\)

Relaciones uno a muchos¶

Veamos un ejemplo en el que permitimos que un «post» de un «blog» admita comentarios:

erDiagram
    POST ||--o{ COMMENT : has

Un «post» tiene cero o muchos comentarios, pero un comentario está relacionado con un único «post».

Partimos de un modelo de «post» habitual:

from django.db import models


class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, unique=True)
    content = models.TextField()

Para relacionar ambos modelos usamos un campo de tipo ForeignKey:

from django.db import models


class Comment(models.Model):
    alias = models.CharField(max_length=128)
    content = models.TextField()
    post = models.ForeignKey(
        'posts.Post',              # Modelo relacionado
        related_name='comments',   # Nombre relacionado
        on_delete=models.CASCADE,  # Acción de borrado
    )

Analicemos cada parámetro de ForeignKey por separado:

Modelo relacionado
Nombre relacionado
Acción de borrado

Modelo relacionado¶

El primer parámetro que recibe ForeignKey es el modelo que vamos a relacionar.

Hay dos formas de indicarlo:

1. Esto permite evitar los llamados «circular imports».

Nombre relacionado¶

El parámetro related_name establece el nombre que podremos usar en el «otro lado de la relación» para recuperar todos los objetos vinculados.

Es una buena práctica que este parámetro se llame como la clase en la que está incluido pero en minúsculas y en plural:

A través del «related name» es posible obtener todos los objetos relacionados. Imaginemos que en el ejemplo del «blog» necesitamos obtener todos los comentarios de un determinado «post»:

>>> from posts.models import Post

>>> post = Post.objects.get(slug='django-is-awesome')
>>> post.comments.all()#(1)!
<QuerySet [<Comment: This is cool>, <Comment: I don't understand it>, <Comment: Please explain it again>]>

1. La forma anti natural podría sería: Comment.objects.filter(post=post)

related_name no es un parámetro requerido, pero es altamente recomendable incluirlo.

Colisión¶

Hay ocasiones en las que se puede producir una colisión si tenemos dos claves ajenas apuntando al mismo modelo y con el mismo related_name.

Pensemos en un ejemplo donde reflejamos el escritor y el editor de un «post»:

class Post(models.Model):
    writer = models.ForeignKey('members.Member', related_name='posts')
    editor = models.ForeignKey('members.Member', related_name='posts')

Obtendríamos un error similar a este:

Reverse accessor 'Member.posts' for 'posts.Post.editor'
clashes with reverse accessor for 'posts.Post.writer'.

En estos casos debemos «romper» la regla y establecer nombres diferentes para related_name:

class Post(models.Model):
    writer = models.ForeignKey('members.Member', related_name='writer_posts')
    editor = models.ForeignKey('members.Member', related_name='editor_posts')

Acción de borrado¶

El parámetro on_delete especifica qué acción debe tomar Django cuando se borra el objeto relacionado.

En el ejemplo anterior, vendría a significar, qué hacemos con los comentarios de un «post» que acabamos de «borrar».

Los posibles valores de este parámetro se muestran en la siguiente tabla:

Claves ajenas nulas¶

Si en el ejemplo anterior, pudieran existir comentarios sin «post» (huérfanos), tendríamos que modificar ligeramente el modelo para admitir valores nulos:

from django.db import models


class Comment(models.Model):
    alias = models.CharField(max_length=128)
    content = models.TextField(max_length=256)
    post = models.ForeignKey(
        'posts.Post',
        related_name='comments',
        on_delete=models.CASCADE,
        blank=True,
        null=True,
    )

Claves ajenas con usuario¶

Es muy habitual relacionar modelos con la clase User predefinida en Django. No es distinto de lo que hemos visto hasta ahora, pero sí vale la pena indicar cómo se referencia.

Siguiendo con el ejemplo del «blog», supongamos que queremos modelar la siguiente relación:

erDiagram
    USER ||--o{ COMMENT : writes

Un usuario escribe cero o muchos comentarios, pero un comentario lo escribe un único usuario.

Por tanto, tendremos que añadir una clave ajena al usuario en el modelo de comentario:

from django.conf import settings
from django.db import models


class Comment(models.Model):
    content = models.TextField()
    post = models.ForeignKey(
        'posts.Post',
        related_name='comments',
        on_delete=models.CASCADE,
    )
    user = models.ForeignKey(
        settings.AUTH_USER_MODEL,#(1)!
        related_name='comments',
        on_delete=models.CASCADE,#(2)!
    )

1. Consulta acceso al modelo de usuario.
2. Si borramos un usuario se borrarán todos sus comentarios.

Operaciones con claves ajenas¶

Veamos a continuación diferentes operaciones que podemos realizar con claves ajenas sobre el ejemplo concreto de los comentarios de un «post» dentro de un «blog»:

>>> from posts.models import Post
>>> from comments.models import Comment

>>> post = Post.create(
...     title='Django makes it very simple',
...     slug='django-makes-it-very-simple',
...     content='You can save related objects quite fast',
... )

>>> comment = Comment.create(
...     alias='sdelquin',
...     content='You are absolutely right!',
...     post=post,#(1)!
... )

>>> from posts.models import Post
>>> from comments.models import Comment

>>> post = Post.objects.get(slug='django-is-awesome')
>>> comment = Comments.objects.get(content='Yes indeed!')

>>> comment.post = post#(1)!
>>> comment.save()

>>> from comments.models import Comment

>>> Comment.objects.filter(post__title__startswith('Future'))#(1)!

>>> from posts.models import Post

>>> post = Post.objects.get(slug='django-is-awesome')
>>> post.comments.delete()#(1)!

>>> comment.post = None#(1)!
>>> comment.save()

Relaciones uno a uno¶

Django ofrece la posibilidad de definir relaciones uno a uno utilizando la clase OneToOneField().

Un caso de uso muy habitual de este tipo de relaciones es cuando queremos extender la información del usuario predefinido en Django.

Extendiendo el modelo de usuario¶

Dado que no tenemos acceso «directo» a modificar el modelo User predefinido en Django hay que buscar otras alternativas para extender dicho modelo.

La opción más «sencilla» es crear un modelo alternativo que disponga de una clave ajena al usuario de tipo uno a uno.

Veamos un ejemplo en el que queremos añadir la profesión y el teléfono a la información de usuario. Crearemos un nuevo modelo denominado Profile (perfil de usuario) que se relaciona con User y que contendrá los atributos «extendidos» de usuario:

erDiagram
    USER ||--|| PROFILE : has

Un usuario tiene un único perfil y cada perfil sólo pertenece a un usuario.

Como se puede observar, se trata de una relación 1:1 por lo que vamos a utilizar la clase OneToOneField() que proporciona Django. La implementación sería la siguiente:

from django.db import models
from django.conf import settings


class Profile(models.Model):
    user = models.OneToOneField(
        settings.AUTH_USER_MODEL,#(1)!
        related_name='profile',#(2)!
        on_delete=models.CASCADE,
    )
    occupation = models.CharField(max_length=256, blank=True)
    phone = models.CharField(max_length=16, blank=True)

1. Se podría poner directamente 'auth.User' aunque este acceso está más desacoplado.
2. Al ser un OneToOneField() el related_name debería ser el nombre de la clase a la que pertenece en minúsculas singular.

Relaciones muchos a muchos¶

Django avanzado

Planteamos el siguiente ejemplo en el que asignamos etiquetas a los «posts» de nuestro «blog»:

erDiagram
    POST }o--o{ LABEL : has

Un «post» tiene cero o muchas etiquetas y una etiqueta puede estar en cero o muchos «posts».

Lo primero será crear las etiquetas a través de un sencillo modelo Label:

from django.db import models


class Label(models.Model):
    name = models.CharField(max_length=128)
    slug = models.SlugField(max_length=128, unique=True)

Para relacionar los «posts» con las etiquetas usaremos un campo de tipo ManyToManyField:

from django.db import models


class Post(models.Model):
    title = models.CharField(max_length=256)
    slug = models.SlugField(max_length=256, unique=True)
    content = models.TextField()
    labels = models.ManyToManyField(#(1)!
        'labels.Label',#(2)!
        related_name='posts',#(3)!
        blank=True,#(4)!
    )

1. El atributo labels hace referencia a múltiples etiquetas que puede tener un «post».
2. El modelo vinculado es Label dentro de la aplicación labels.
3. El parámetro related_name funciona igual que en casos anteriores.
4. Específico para este caso en el que pueden haber «posts» que no tengan etiquetas.

Lo primero será crear etiquetas y «posts»:

>>> from labels.models import Label
>>> from posts.models import Post

>>> label_tech = Label.objects.create(name='Technology', slug='tech')
>>> label_ai = Label.objects.create(name='Artificial Intelligence', slug='ai')

>>> post_python = Post.objects.create(
...     title='Python',
...     slug='python',
...     content='Now is better than never',
... )
>>> post_midjourney = Post.objects.create(
...     title='Midjourney',
...     slug='midjourney',
...     content='Awesome images',
... )

Ahora podemos realizar distintas operaciones sobre el campo labels de tipo «muchos a muchos»:

>>> post_python.labels.add(label_tech)#(1)!

>>> label_ai.posts.add(post_midjourney)#(1)!

>>> post_python.labels.create(name='Technology', slug='tech')#(1)!
<Label: Technology>

>>> label_ai.posts.create(title='Midjourney', content='Awesome images')#(1)!
<Post: Midjourney>

>>> post_python.labels.set([label_tech, label_ai])#(1)!

>>> label_ai.posts.set([post_python, post_midjourney])#(1)!

>>> post_python.labels.remove(label_ai)#(1)!