Meta para modelos¶Este documento explica todas las opciones de metadatos posibles que puedes dar a tu modelo en su class Meta interna.
Meta opciones¶abstract¶Si abstract = True, este modelo será una clase base abstracta:ref:clases-base-abstractas.
Si un modelo se define fuera de una aplicación en INSTALLED_APPS, debe declarar a qué aplicación pertenece:
app_label = "myapp"
Si deseas representar un modelo con el formato app_label.object_name o app_label.model_name, puedes usar model._meta.label o model._meta.label_lower respectivamente.
base_manager_name¶El nombre de la propiedad del administrador, por ejemplo, 'objects', para utilizar en el _base_manager del modelo.
db_table¶El nombre de la tabla de base de datos a utilizar para el modelo:
db_table = "music_album"
Para ahorrarte tiempo, Django deriva automáticamente el nombre de la tabla de base de datos desde el nombre de tu clase de modelo y la aplicación que contiene. El nombre de la tabla de base de datos del modelo se construye uniendo el «etiqueta de la aplicación» – el nombre que utilizaste en manage.py startapp – al nombre de la clase del modelo, con un guión bajo entre ellos.
Por ejemplo, si tienes una aplicación bookstore (como se crea con manage.py startapp bookstore), un modelo definido como class Book tendrá una tabla de la base de datos llamada bookstore_book.
Para sobreescribir el nombre de la tabla de la base de datos, utiliza el parámetro db_table en class Meta.
Si el nombre de tu tabla de la base de datos es una palabra reservada SQL o contiene caracteres que no están permitidos en nombres de variables Python – notoriamente, el guión – eso está bien. Django cita los nombres de columnas y tablas detrás de escena.
Utiliza nombres de tabla en minúsculas para MariaDB y MySQL
Es fuertemente recomendado que utilices nombres de tabla en minúsculas cuando sobreescribas el nombre de la tabla mediante db_table, particularmente si estás utilizando el backend de MySQL. Consulta las notas sobre MySQL <mysql-notes> para obtener más detalles.
Nombre de tabla con comillas para Oracle
Para cumplir con la limitación de 30 caracteres que tiene Oracle en nombres de tablas, y coincidir con las convenciones habituales para bases de datos Oracle, Django puede acortar los nombres de tablas y convertirlos a mayúsculas. Para evitar tales transformaciones, utiliza un nombre entre comillas como valor para db_table:
db_table = '"name_left_in_lowercase"'
También se pueden utilizar estos nombres con comillas en los otros backends de base de datos admitidos por Django; excepto Oracle, sin embargo, las comillas no tienen efecto. Consulta las notas sobre Oracle <oracle-notes> para obtener más detalles.
db_table_comment¶El comentario sobre la tabla de la base de datos que se utilizará para este modelo. Es útil para documentar tablas de la base de datos para individuos con acceso directo a la base de datos que no estén mirando tu código Django. Por ejemplo:
class Answer(models.Model):
question = models.ForeignKey(Question, on_delete=models.CASCADE)
answer = models.TextField()
class Meta:
db_table_comment = "Question answers"
db_tablespace¶El nombre de la espacio de nombres de base de datos a utilizar para este modelo. El valor por defecto es el establecido en la configuración del proyecto DEFAULT_TABLESPACE, si está definido. Si el backend no admite espacios de nombres, esta opción se ignora.
default_manager_name¶El nombre del administrador a utilizar para el modelo _default_manager.
get_latest_by¶El nombre de un campo o una lista de nombres de campos en el modelo, típicamente DateField, DateTimeField o IntegerField. Esto especifica los campos por defecto a utilizar en el método latest() y earliest() del administrador Manager de tu modelo.
Ejemplo:
# Latest by ascending order_date.
get_latest_by = "order_date"
# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]
Consulta la documentación de los métodos latest() para obtener más información.
Por defecto es True, lo que significa que Django creará las tablas de la base de datos adecuadas en migrate o como parte de las migraciones y las eliminará como parte del comando de gestión flush. Es decir, Django gestiona los ciclos de vida de las tablas de la base de datos.
Si es False, no se realizarán operaciones de creación, modificación o eliminación de tablas de la base de datos para este modelo. Esto es útil si el modelo representa una tabla existente o una vista de la base de datos que ha sido creada por algún otro medio. Esta es la única diferencia cuando managed=False. Todos los demás aspectos del manejo del modelo son exactamente los mismos que normales. Esto incluye
Agregar un campo primario automático al modelo si no se declara explícitamente. Para evitar confusiones para lectores de código posteriores, se recomienda especificar todas las columnas de la tabla de la base de datos que estás modelando cuando usas modelos no administrados.
Si un modelo con managed=False contiene una relación ManyToManyField que apunta a otro modelo no administrado, entonces también no se creará la tabla intermedia para la unión muchos-a-muchos. Sin embargo, la tabla intermedia entre un modelo administrado y uno no administrado sí se creará.
Si necesitas cambiar este comportamiento por defecto, crea la tabla intermedia como un modelo explícito (con managed configurado según sea necesario) y utiliza el atributo ManyToManyField.through para hacer que la relación utilice tu modelo personalizado.
Para pruebas que involucran modelos con managed=False, es responsabilidad tuya asegurarte de que las tablas correctas se crean como parte del setup de la prueba.
Si estás interesado en cambiar el comportamiento a nivel de Python de una clase de modelo, podrías usar managed=False y crear una copia de un modelo existente. Sin embargo, hay una mejor forma para esa situación: Modelos proxy.
Hace que este objeto sea ordenable con respecto al campo dado, generalmente un ForeignKey. Esto se puede utilizar para hacer que los objetos relacionados sean ordenables con respecto a un objeto padre. Por ejemplo, si una respuesta se relaciona con un objeto de pregunta y una pregunta tiene más de una respuesta y el orden de las respuestas importa, harías esto:
from django.db import models
class Question(models.Model):
text = models.TextField()
# ...
class Answer(models.Model):
question = models.ForeignKey(Question, on_delete=models.CASCADE)
# ...
class Meta:
order_with_respect_to = "question"
When order_with_respect_to está configurado, se proporcionan dos métodos adicionales para recuperar y establecer el orden de los objetos relacionados: get_RELATED_order() y set_RELATED_order(), donde RELATED es el nombre del modelo en minúsculas. Por ejemplo, suponiendo que un objeto Question tiene múltiples objetos relacionados Answer, la lista devuelta contiene las claves primarias de los objetos relacionados Answer:
>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]
El orden de los objetos relacionados Answer de un objeto Question se puede establecer pasando una lista de claves primarias de Answer:
>>> question.set_answer_order([3, 1, 2])
Los objetos relacionados también obtienen dos métodos, get_next_in_order() y get_previous_in_order(), que se pueden utilizar para acceder a esos objetos en su orden correcto. Suponiendo que los objetos Answer están ordenados por id:
>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>
order_with_respect_to establece implícitamente la opción ordering
Internamente, order_with_respect_to agrega un campo adicional/directiva de base de datos llamado _order y establece la opción ordering del modelo en este campo. Consecuentemente, order_with_respect_to y ordering no pueden usarse juntos, y el orden agregado por order_with_respect_to se aplicará siempre que obtengas una lista de objetos de este modelo.
Cambiar order_with_respect_to
Porque order_with_respect_to agrega un campo adicional en la base de datos, asegúrate de crear y aplicar las migraciones adecuadas si agregas o cambias order_with_respect_to después de tu primera migrate.
ordering¶El ordenamiento predeterminado del objeto, para uso cuando se obtienen listas de objetos:
ordering = ["-order_date"]
Este es un tupla o lista de cadenas y/o expresiones de consulta. Cada cadena es el nombre de un campo con una opción prefixo «-», que indica orden descendente. Los campos sin un prefijo «-» serán ordenados en ascenso. Utiliza la cadena «?» para ordenar al azar.
Para ordenar por un campo pub_date ascendente, utiliza esto:
ordering = ["pub_date"]
Para ordenar por pub_date descendente, utiliza esto:
ordering = ["-pub_date"]
Para ordenar por pub_date descendente y luego por author ascendente, utiliza esto:
ordering = ["-pub_date", "author"]
También puedes utilizar expresiones de consulta. Para ordenar por author ascendente y hacer que los valores nulos se ordenen al final, utiliza esto:
from django.db.models import F
ordering = [F("author").asc(nulls_last=True)]
Ordenación predeterminada y GROUP BY
En las consultas GROUP BY (por ejemplo, aquellas que utilizan values() y annotate()), la ordenación predeterminada no se aplica.
Advertencia
La ordenación no es una operación gratuita. Cada campo que agregues a la ordenación incurre en un costo para tu base de datos. Cada clave foránea que agregues incluirá implícitamente todas sus ordenaciones por defecto también.
Si una consulta no tiene una ordenación especificada, los resultados se devuelven desde la base de datos en un orden no especificado. Una particular ordenación está garantizada solo cuando se ordena por un conjunto de campos que identifiquen únicamente cada objeto en los resultados. Por ejemplo, si un campo name no es único, ordenar por él no garantiza que los objetos con el mismo nombre siempre aparezcan en el mismo orden.
permissions¶Permisos adicionales para ingresar a la tabla de permisos al crear este objeto. Se crean automáticamente permisos de agregar, cambiar, eliminar y visualizar para cada modelo. Este ejemplo especifica un permiso adicional, can_deliver_pizzas:
permissions = [("can_deliver_pizzas", "Can deliver pizzas")]
Esta es la lista de permisos o tuplas en formato (permiso_codigo, nombre_permiso_legible).
Por defecto se establece como (“add”, “change”, “delete”, “view”). Puedes personalizar esta lista, por ejemplo, estableciéndola en una lista vacía si tu aplicación no requiere ninguno de los permisos predeterminados. Debe especificarse en el modelo antes de que el modelo sea creado mediante migrate para evitar que se creen permisos omitidos.
Lista de características del motor de base de datos que la conexión actual debe tener para que el modelo se considere durante la fase de migración. Por ejemplo, si estableces esta lista como [“gis_enabled”], el modelo solo será sincronizado en bases de datos GIS habilitadas. También es útil saltar algunos modelos cuando se esté probando con varios backends de base de datos. Evita las relaciones entre modelos que pueden o no ser creadas ya que la ORM no maneja esto.
Nombre del proveedor de bases de datos admitido a la que este modelo es específico. Los nombres de los proveedores de base de datos integrados actuales son: sqlite, postgresql, mysql, oracle. Si esta atributo no está vacío y el proveedor actual de conexión no coincide con él, el modelo no será sincronizado.
Determina si Django utilizará el algoritmo pre-1.6 de django.db.models.Model.save() . El antiguo algoritmo utiliza SELECT para determinar si existe una fila existente que debe actualizarse. El nuevo algoritmo intenta un UPDATE directo. En algunos casos raros, el UPDATE de una fila existente no es visible para Django. Un ejemplo es el trigger ON UPDATE PostgreSQL que devuelve NULL . En tales casos, el nuevo algoritmo terminará haciendo un INSERT incluso cuando hay una fila en la base de datos.
Normalmente no es necesario establecer este atributo. El valor por defecto es False .
Consulte django.db.models.Model.save() para más información sobre los algoritmos de guardado antiguo y nuevo.
índices¶Una lista de índices que deseas definir en el modelo:
from django.db import models
class Customer(models.Model):
first_name = models.CharField(max_length=100)
last_name = models.CharField(max_length=100)
class Meta:
indexes = [
models.Index(fields=["last_name", "first_name"]),
models.Index(fields=["first_name"], name="first_name_idx"),
]
unique_together¶Conjuntos de nombres de campos que, considerados juntos, deben ser únicos:
unique_together = [["driver", "restaurant"]]
Esto es una lista de listas que deben ser únicas cuando se consideran juntas. Se utiliza en la interfaz administrativa de Django y se aplica a nivel de base de datos (es decir, se incluyen las declaraciones UNIQUE adecuadas en el comando CREATE TABLE ).
Los textos traducidos son:
unique_together = ["driver", "restaurant"]
Una ManyToManyField no puede incluirse en unique_together. (No está claro qué significaría eso!) Si necesitas validar la unicidad relacionada con una ManyToManyField, prueba utilizando un señal o un modelo explícito de through.
La excepción ValidationError lanzada durante la validación del modelo cuando se viola el constraint tiene el código de error unique_together.
constraints¶Una lista de restricciones que deseas definir en el modelo:
from django.db import models
class Customer(models.Model):
age = models.IntegerField()
class Meta:
constraints = [
models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),
]
Un nombre legible por humanos para el objeto, singular:
verbose_name = "pizza"
Si no se proporciona esto, Django utilizará una versión «menguada» del nombre de la clase: CamelCase se convierte en camel case.
verbose_name_plural¶El nombre plural para el objeto:
verbose_name_plural = "stories"
Si no se proporciona esto, Django utilizará verbose_name + "s".
label¶Representación del objeto, devuelve app_label.object_name, por ejemplo 'polls.Question'.
Representación del modelo, devuelve app_label.model_name, por ejemplo 'polls.question'.
may 31, 2026