Opciones del campo
Los siguientes argumentos están disponibles para todos los tipos de campo. Todos son opcionales.
null
-
Field.null
Si True, Django almacenará valores vacíos como NULL en la base de datos. Por defecto es False.
Evita utilizar :attr:`~Field.null en campos basados en cadenas como CharField y TextField. La convención de Django es usar una cadena vacía, no NULL, como estado «sin datos» para los campos basados en cadenas. Si un campo basado en cadenas tiene null=False, aún se pueden guardar cadenas vacías para «sin datos». Si un campo basado en cadenas tiene null=True, eso significa que tiene dos valores posibles para «sin datos»: NULL, y la cadena vacía. En la mayoría de los casos, es redundante tener dos valores posibles para «sin datos». Una excepción es cuando un CharField tiene ambos unique=True y blank=True configurados. En esta situación, null=True se requiere para evitar violaciones de restricciones únicas al guardar múltiples objetos con valores en blanco.
Para ambos campos basados en cadenas y no basados en cadenas, también necesitarás establecer blank=True si deseas permitir valores vacíos en formularios, ya que el parámetro de atributo null solo afecta al almacenamiento en la base de datos (consultar blank).
Nota
Cuando se utiliza la base de datos backend Oracle, el valor NULL se almacenará para denotar la cadena vacía independientemente de esta atributo.
blank
-
Field.blank
Si True, el campo se permite estar en blanco. Por defecto es False.
Ten en cuenta que esto es diferente de null. null es puramente relacionado con la base de datos, mientras que blank es relacionado con la validación. Si un campo tiene blank=True, la validación de formularios permitirá la entrada de un valor vacío. Si un campo tiene blank=False, el campo será obligatorio.
Proporcionando valores faltantes
blank=True se puede utilizar con campos que tengan null=False, pero esto requerirá implementar el método clean() en el modelo para suministrar de forma programática los valores faltantes.
choices
-
Field.choices[fuente]
Una mapeo o iterable en el formato descrito a continuación, para utilizar como opciones para este campo. Si se dan opciones, se aplican mediante la validación del modelo y el widget de formulario predeterminado será un select box con estas opciones en lugar del campo de texto estándar.
Si se da un mapeo, el elemento clave es el valor real a establecer en el modelo, y el segundo elemento es el nombre legible por humanos. Por ejemplo:
YEAR_IN_SCHOOL_CHOICES = {
"FR": "Freshman",
"SO": "Sophomore",
"JR": "Junior",
"SR": "Senior",
"GR": "Graduate",
}
También puedes pasar una secuencia consistente en iterables de exactamente dos elementos (por ejemplo [(A1, B1), (A2, B2), …]). El primer elemento en cada tupla es el valor real a establecer en el modelo, y el segundo elemento es el nombre legible por humanos. Por ejemplo:
YEAR_IN_SCHOOL_CHOICES = [
("FR", "Freshman"),
("SO", "Sophomore"),
("JR", "Junior"),
("SR", "Senior"),
("GR", "Graduate"),
]
choices también se pueden definir como un callable que no espera argumentos y devuelve cualquiera de los formatos descritos anteriormente. Por ejemplo:
def get_currencies():
return {i: i for i in settings.CURRENCIES}
class Expense(models.Model):
amount = models.DecimalField(max_digits=10, decimal_places=2)
currency = models.CharField(max_length=3, choices=get_currencies)
Pasando un callable para choices puede ser particularmente útil cuando, por ejemplo, las opciones son:
el resultado de operaciones I/O-bindeadas (que podrían potencialmente ser cacheadas), como consultar una tabla en la misma o una base de datos externa, o acceder a las opciones desde un archivo estático.
una lista que es principalmente estable pero podría variar con el tiempo o entre proyectos. Ejemplos en esta categoría son utilizar aplicaciones de terceros que proporcionan una inventario bien conocido de valores, como monedas, países, idiomas, zonas horarias, etc.
En general, es mejor definir opciones dentro de una clase de modelo y definir un constante con nombre adecuado para cada valor:
from django.db import models
class Student(models.Model):
FRESHMAN = "FR"
SOPHOMORE = "SO"
JUNIOR = "JR"
SENIOR = "SR"
GRADUATE = "GR"
YEAR_IN_SCHOOL_CHOICES = {
FRESHMAN: "Freshman",
SOPHOMORE: "Sophomore",
JUNIOR: "Junior",
SENIOR: "Senior",
GRADUATE: "Graduate",
}
year_in_school = models.CharField(
max_length=2,
choices=YEAR_IN_SCHOOL_CHOICES,
default=FRESHMAN,
)
def is_upperclass(self):
return self.year_in_school in {self.JUNIOR, self.SENIOR}
A continuación se presentan las traducciones de los textos originales.
También puedes recopilar tus opciones disponibles en grupos nombrados que se pueden utilizar con fines organizativos:
MEDIA_CHOICES = {
"Audio": {
"vinyl": "Vinyl",
"cd": "CD",
},
"Video": {
"vhs": "VHS Tape",
"dvd": "DVD",
},
"unknown": "Unknown",
}
La clave de la asignación es el nombre a aplicar al grupo y el valor son las opciones dentro de ese grupo, consistiendo en el valor del campo y un nombre legible por humanos para una opción. Las opciones agrupadas pueden combinarse con opciones no agrupadas dentro de una sola asignación (como la opción "desconocido" en este ejemplo).
También puedes utilizar una secuencia, p. ej., una lista de 2-tuplas:
MEDIA_CHOICES = [
(
"Audio",
(
("vinyl", "Vinyl"),
("cd", "CD"),
),
),
(
"Video",
(
("vhs", "VHS Tape"),
("dvd", "DVD"),
),
),
("unknown", "Unknown"),
]
Ten en cuenta que las opciones pueden ser cualquier objeto de secuencia – no necesariamente una lista o tupla. Esto te permite construir opciones dinámicamente. Pero si encuentras que estás «hackeando» choices para hacerlo dinámico, probablemente estarías mejor utilizando una tabla de la base de datos con un ForeignKey. choices está destinado a datos estáticos que no cambian mucho, o nunca.
Nota
Se crea una nueva migración cada vez que cambia el orden de choices.
Para cada campo del modelo que tenga establecido choices, Django normalizará las opciones en una lista de 2-tuplas y agregará un método para recuperar el nombre legible por humanos para el valor actual del campo. Consulta get_FOO_display() en la documentación de la API de base de datos.
A menos que se establezca blank=False junto con un default en el campo, entonces se renderizará una etiqueta conteniendo "---------" con el cuadro desplegable. Para sobreescribir este comportamiento, agrega una tupla a choices conteniendo None; p. ej., (None, 'Tu cadena para mostrar'). Alternativamente, puedes utilizar una cadena vacía en lugar de None donde esto tenga sentido - como en un CharField.
Tipos de enumeración
Además, Django proporciona tipos de enumeración que puedes heredar para definir opciones de manera concisa:
from django.utils.translation import gettext_lazy as _
class Student(models.Model):
class YearInSchool(models.TextChoices):
FRESHMAN = "FR", _("Freshman")
SOPHOMORE = "SO", _("Sophomore")
JUNIOR = "JR", _("Junior")
SENIOR = "SR", _("Senior")
GRADUATE = "GR", _("Graduate")
year_in_school = models.CharField(
max_length=2,
choices=YearInSchool,
default=YearInSchool.FRESHMAN,
)
def is_upperclass(self):
return self.year_in_school in {
self.YearInSchool.JUNIOR,
self.YearInSchool.SENIOR,
}
Estos funcionan de manera similar a enum de la biblioteca estándar de Python, pero con algunas modificaciones:
Los valores de los miembros enumerados son una tupla de argumentos para utilizar al construir el tipo de datos concreto. Django admite agregar un valor de cadena adicional al final de esta tupla para ser utilizado como nombre legible por humanos, o label. El label puede ser una cadena translatable relajada. Por lo tanto, en la mayoría de los casos, el valor del miembro será una tupla de 2 elementos (valor, label). Consulte a continuación un ejemplo de subclasear utilizando un tipo de datos más complejo. Si no se proporciona una tupla o el último elemento no es una cadena (relajada) de string, el label se genera automáticamente desde el nombre del miembro.
Se agrega la propiedad .label en los valores para devolver el nombre legible por humanos.
Se agregan varias propiedades personalizadas a las clases enumeradas – .choices, .labels, .values, y .names – para hacer más fácil acceder a listas de esas partes separadas del enum.
Advertencia
Los nombres de estas propiedades no pueden usarse como nombres de miembros ya que confluirían.
Se aplica el uso de enum.unique() para asegurar que los valores no se definen múltiples veces. Esto es poco probable que sea esperado en las opciones de un campo.
Ten en cuenta que utilizar YearInSchool.SENIOR, YearInSchool['SENIOR'], o YearInSchool('SR') para acceder o buscar miembros enumerados funcionan como se espera, así como los propiedades .name y .value en los miembros.
Si no necesitas tener los nombres legibles por humanos traducidos, puedes hacer que se infieran del nombre del miembro (sustituyendo los guiones bajo con espacios y utilizando mayúsculas iniciales):
>>> class Vehicle(models.TextChoices):
... CAR = "C"
... TRUCK = "T"
... JET_SKI = "J"
...
>>> Vehicle.JET_SKI.label
'Jet Ski'
Dado que el caso donde los valores de enum necesitan ser enteros es extremadamente común, Django proporciona la clase IntegerChoices. Por ejemplo:
class Card(models.Model):
class Suit(models.IntegerChoices):
DIAMOND = 1
SPADE = 2
HEART = 3
CLUB = 4
suit = models.IntegerField(choices=Suit)
También es posible hacer uso de la API Funcional del Enum con la salvedad de que los labels se generan automáticamente como se destaca arriba:
>>> MedalType = models.TextChoices("MedalType", "GOLD SILVER BRONZE")
>>> MedalType.choices
[('GOLD', 'Gold'), ('SILVER', 'Silver'), ('BRONZE', 'Bronze')]
>>> Place = models.IntegerChoices("Place", "FIRST SECOND THIRD")
>>> Place.choices
[(1, 'First'), (2, 'Second'), (3, 'Third')]
Si requieres soporte para un tipo de datos concreto distinto a int o str, puedes heredar de Choices y del tipo de datos concreto requerido, por ejemplo date para su uso con DateField.
class MoonLandings(datetime.date, models.Choices):
APOLLO_11 = 1969, 7, 20, "Apollo 11 (Eagle)"
APOLLO_12 = 1969, 11, 19, "Apollo 12 (Intrepid)"
APOLLO_14 = 1971, 2, 5, "Apollo 14 (Antares)"
APOLLO_15 = 1971, 7, 30, "Apollo 15 (Falcon)"
APOLLO_16 = 1972, 4, 21, "Apollo 16 (Orion)"
APOLLO_17 = 1972, 12, 11, "Apollo 17 (Challenger)"
Hay algunas consideraciones adicionales de las cuales debes ser consciente:
Tipos de enumeración no admiten grupos nombrados.
Porque una enumeración con un tipo de datos concreto requiere que todos los valores coincidan con el tipo, no se puede lograr sobrescribir la etiqueta blank label creando un miembro con un valor de None. En su lugar, establezca el atributo __empty__ en la clase:
class Answer(models.IntegerChoices):
NO = 0, _("No")
YES = 1, _("Yes")
__empty__ = _("(Unknown)")
db_column
-
Field.db_column
El nombre de la columna de la base de datos que utilizar para este campo. Si no se proporciona, Django utilizará el nombre del campo.
Si el nombre de tu columna de base de datos es una palabra reservada SQL o contiene caracteres que no están permitidos en los nombres de variables de Python —notablemente, la diagonal—, eso está bien. Django pone comillas a los nombres de columnas y tablas detrás de escena.
db_default
-
Field.db_default
El valor por defecto calculado por la base de datos para este campo. Este puede ser un valor literal o una función de la base de datos, como Now:
created = models.DateTimeField(db_default=Now())
Se pueden utilizar expresiones más complejas, siempre y cuando estén hechas a partir de literales y funciones de la base de datos:
month_due = models.DateField(
db_default=TruncMonth(
Now() + timedelta(days=90),
output_field=models.DateField(),
)
)
Los valores por defecto de la base de datos no pueden referirse a otros campos o modelos. Por ejemplo, esto es inválido:
end = models.IntegerField(db_default=F("start") + 50)
Si se establecen tanto db_default como Field.default, default tendrá prioridad al crear instancias en código Python. db_default seguirá estando configurado a nivel de base de datos y se utilizará cuando se inserten filas fuera del ORM o cuando se agregue un nuevo campo en una migración.
Si un campo tiene un db_default sin establecer default y no se asigna ningún valor al campo, se devuelve un objeto DatabaseDefault como el valor del campo en instancias de modelo no guardadas. El valor real para el campo se determina por la base de datos cuando se guarde la instancia de modelo.
db_index
-
Field.db_index
Si es True, se creará un índice de la base de datos para este campo.
Utiliza en su lugar la opción indexes.
Donde sea posible, utilice la opción Meta.indexes en lugar de db_index. En casi todos los casos, indexes proporciona más funcionalidad que db_index. db_index puede ser deprecado en el futuro.
default
-
Field.default
El valor por defecto para el campo. Esto puede ser un valor o un objeto callable. Si es callable se llamará cada vez que se cree una nueva instancia del modelo.
El valor por defecto no puede ser un objeto mutable (instancia de modelo, list, set, etc.), ya que se utilizaría como referencia al mismo objeto en todas las nuevas instancias del modelo. En su lugar, envuélvete el valor deseado en una función callable. Por ejemplo, si quieres especificar un valor por defecto dict para JSONField, utiliza una función:
def contact_default():
return {"email": "to1@example.com"}
contact_info = JSONField("ContactInfo", default=contact_default)
No se pueden utilizar lambdas como opciones de campo como default porque no pueden ser serializadas por las migraciones. Consulta la documentación sobre otras limitaciones.
Para campos como ForeignKey que mapean a instancias del modelo, los valores por defecto deben ser el valor de los campos a los que se refieren (pk a menos que to_field esté configurado) en lugar de instancias del modelo.
El valor por defecto se utiliza cuando se crean nuevas instancias del modelo y no se proporciona un valor para el campo. Cuando el campo es una clave primaria, también se utiliza el valor por defecto cuando el campo está establecido en None.
También puedes configurar el valor por defecto a nivel de base de datos con Field.db_default.
editable
-
Field.editable
Si es False, el campo no se mostrará en la interfaz administrativa ni en cualquier otro ModelForm. También se saltará durante la validación del modelo. El valor por defecto es True.
error_messages
-
Field.error_messages[fuente]
Los textos traducidos son:
Las claves de los mensajes de error incluyen null, blank, invalid, invalid_choice, unique, y unique_for_date. Las claves adicionales de mensajes de error se especifican para cada campo en la sección Tipos de campos a continuación.
Estos mensajes de error a menudo no se propagan a las formas. Consulte consideraciones-regarding-model-errormessages.
help_text
-
Field.help_text
El texto de ayuda adicional para ser mostrado con el widget de la forma. Es útil para la documentación incluso si tu campo no está utilizado en una forma.
Ten en cuenta que este valor no se escape a HTML en las formas generadas automáticamente. Esto te permite incluir HTML en help_text si lo deseas. Por ejemplo:
help_text = "Please use the following format: <em>YYYY-MM-DD</em>."
Alternativamente, puedes usar texto plano y django.utils.html.escape() para escapar cualquier carácter especial de HTML. Asegúrate de escapar cualquier texto de ayuda que pueda provenir de usuarios no confiables para evitar un ataque de inyección de código cruzado.
primary_key
-
Field.primary_key
Si True, este campo es la clave primaria del modelo.
Si no especificas primary_key=True para ningún campo en tu modelo y no has definido una clave primaria compuesta, Django agregará automáticamente un campo para contener la clave primaria. Por lo tanto, no necesitas establecer primary_key=True en ninguno de tus campos a menos que desees sobreescribir el comportamiento predeterminado de la clave primaria. El tipo de los campos de clave primaria auto-creados se puede especificar por aplicación en AppConfig.default_auto_field o globalmente en la configuración DEFAULT_AUTO_FIELD. Para más información, consulta campos de clave primaria auto-creados.
primary_key=True implica null=False y unique=True. Solo un campo por modelo puede establecer primary_key=True. Las claves primarias compuestas deben definirse utilizando CompositePrimaryKey en lugar de establecer esta bandera para todos los campos para mantener esta invariante.
El campo de clave primaria es de solo lectura. Si cambias el valor de la clave primaria en un objeto existente y luego lo guardas, se creará un nuevo objeto junto al antiguo.
El campo de clave primaria se establece en None cuando se elimina un objeto mediante deleting.
Se agregó el campo CompositePrimaryKey.
único
-
Field.unique[fuente]
Si True, este campo debe ser único a lo largo de la tabla.
Esto se aplica tanto en el nivel del servidor de bases de datos como mediante la validación del modelo. Si intentas guardar un modelo con un valor duplicado en un campo unique, se levantará una django.db.IntegrityError por parte del método save() del modelo.
Esta opción es válida para todos los tipos de campos excepto ManyToManyField y OneToOneField.
Ten en cuenta que cuando unique es True, no necesitas especificar db_index, porque unique implica la creación de un índice.
unique_for_date
-
Field.unique_for_date
Establece esto con el nombre de un campo DateField o DateTimeField para requerir que este campo sea único para el valor del campo de fecha.
Por ejemplo, si tienes un campo title con unique_for_date="pub_date", entonces Django no permitirá la entrada de dos registros con el mismo title y pub_date.
Tenga en cuenta que si establece esto para apuntar a un campo de tipo DateTimeField, solo se considerará la parte de fecha del campo. Además, cuando USE_TZ esté configurado como True, el chequeo se realizará en la zona horaria actual <default-current-time-zone> al momento en que el objeto se guarde.
Esto se impone mediante Model.validate_unique() durante la validación del modelo, pero no a nivel de base de datos. Si alguna restricción de unique_for_date involucra campos que no forman parte de un formulario de modelo ModelForm (por ejemplo, si uno de los campos está en exclude o tiene editable=False), Model.validate_unique() saltará la validación para esa restricción particular.
unique_for_month
-
Field.unique_for_month
Al igual que unique_for_date, pero requiere que el campo sea único con respecto al mes.
verbose_name
-
Field.verbose_name
Un nombre legible por humanos para el campo. Si no se proporciona un nombre verbal, Django creará automáticamente uno utilizando el nombre de atributo del campo, convirtiendo los guiones bajos en espacios. Consulte la documentación sobre <verbose-field-names> nombres de campos verbales.
validators
-
Field.validators[fuente]
Una lista de validadores para ejecutar para este campo. Consulte la documentación sobre <ref/validators> validadores para obtener más información.
Tipos de campos
AutoField
-
class AutoField(**options)[fuente]
Un IntegerField que incrementa automáticamente según estén disponibles los IDs. Normalmente no necesitarás utilizar este directamente; un campo de clave primaria se agregará automáticamente a tu modelo si no especificas lo contrario. Consulta la sección campos-de-llave-primaria-automaticos.
BigAutoField
-
class BigAutoField(**options)[fuente]
Un entero de 64 bits, similar a un AutoField excepto que está garantizado que encajará números desde 1 hasta 9223372036854775807.
BigIntegerField
-
class BigIntegerField(**options)[fuente]
Un entero de 64 bits, similar a un IntegerField excepto que está garantizado que encajará números desde -9223372036854775808 hasta 9223372036854775807. El widget de formulario por defecto para este campo es una NumberInput.
BinaryField
-
class BinaryField(max_length=None, **options)[fuente]
Un campo para almacenar datos binarios crudos. Puede asignarse bytes, bytearray o memoryview.
Por defecto, BinaryField establece editable en False, en cuyo caso no se puede incluir en un ModelForm.
-
BinaryField.max_length
Opcional. La longitud máxima (en bytes) del campo. La longitud máxima se aplica mediante la validación de Django utilizando MaxLengthValidator.
Abusando de BinaryField
Aunque podrías pensar en almacenar archivos en la base de datos, considera que es una mala práctica en el 99% de los casos. Este campo no es un reemplazo para manejar las archivos estáticos correctamente.
CompositePrimaryKey
-
class CompositePrimaryKey(*field_names, **options)[fuente]
Un campo virtual utilizado para definir una clave primaria compuesta.
Este campo debe ser definido como la atributo pk del modelo. Si está presente, Django creará la tabla de modelo subyacente con una clave primaria compuesta.
El argumento *field_names es una lista de nombres de campos posicionales que componen la clave primaria.
Consulte Claves primarias compuestas para obtener más detalles.
CharField
-
class CharField(max_length=None, **options)[fuente]
Un campo de cadena para cadenas pequeñas a grandes.
Para cantidades grandes de texto, utilice TextField.
El widget de formulario predeterminado para este campo es un TextInput.
CharField tiene los siguientes argumentos adicionales:
-
CharField.max_length
La longitud máxima (en caracteres) del campo. El max_length se aplica en el nivel de la base de datos y en la validación de Django utilizando MaxLengthValidator. Es obligatorio para todos los backends de bases de datos incluidos con Django excepto PostgreSQL y SQLite, que admiten columnas VARCHAR ilimitadas.
Nota
Si está escribiendo una aplicación que debe ser portátil a múltiples backends de base de datos, debería tener en cuenta las restricciones del max_length para algunos backends. Consulte los notas sobre el backend de la base de datos para obtener más detalles.
Se agregó soporte a columnas VARCHAR ilimitadas en SQLite.
-
CharField.db_collation
Opcional. El nombre de collación de la base de datos del campo.
Nota
Los nombres de collación no están estandarizados. Como tal, esto no será portátil entre múltiples backends de bases de datos.
Oracle
Oracle admite solo las collaciones cuando el parámetro de inicialización de la base de datos MAX_STRING_SIZE está configurado en EXTENDED.
DateField
-
class DateField(auto_now=False, auto_now_add=False, **options)[fuente]
La fecha, representada en Python por una instancia de datetime.date. Tiene unos pocos argumentos adicionales y opcionales:
-
DateField.auto_now
Establece automáticamente el campo a la fecha actual cada vez que se guarda el objeto. Útil para «timestamp de última modificación». Ten en cuenta que siempre se utiliza la fecha actual; no es solo un valor por defecto que puedes sobrescribir.
El campo se actualiza automáticamente solo cuando se llama al método Model.save(). El campo no se actualiza cuando se realizan actualizaciones de otros campos de otras maneras, como QuerySet.update(), aunque puedes especificar un valor personalizado para el campo en una actualización como esa.
-
DateField.auto_now_add
Establece automáticamente el campo a la fecha actual cuando se crea el objeto por primera vez. Útil para la creación de timestamps. Ten en cuenta que siempre se utiliza la fecha actual; no es solo un valor por defecto que puedes sobrescribir. Por lo tanto, incluso si estableces un valor para este campo al crear el objeto, se ignorará. Si deseas poder modificar este campo, configura las siguientes opciones en lugar de auto_now_add=True:
El widget de formulario predeterminado para este campo es un DateInput. El admin agrega un calendario JavaScript y una atajo para «Hoy». Incluye un mensaje de error adicional invalid_date.
Las opciones auto_now_add, auto_now y default son mutuamente excluyentes. Cualquier combinación de estas opciones dará como resultado un error.
Nota
Como se implementa actualmente, establecer auto_now o auto_now_add en True causará que el campo tenga editable=False y blank=True configurados.
Nota
Las opciones auto_now y auto_now_add siempre utilizarán la fecha en la zona horaria por defecto en el momento de creación o actualización. Si necesitas algo diferente, podrías considerar usar un valor predeterminado llamable propio o sobrescribir save() en lugar de usar auto_now o auto_now_add; o utilizar un DateTimeField en lugar de un DateField y decidir cómo manejar la conversión de datetime a date en el momento del display.
Advertencia
Always use DateField con una instancia de datetime.date.
Si tienes una instancia de datetime.datetime, se recomienda convertirla a datetime.date primero. Si no lo haces, DateField localizará la datetime.datetime en el zona horaria por defecto y la convertirá a una instancia de datetime.date, eliminando su componente de tiempo. Esto es cierto tanto para el almacenamiento como para la comparación.
Advertencia
En PostgreSQL y MySQL, las operaciones aritméticas en un DateField con una timedelta devuelven un datetime en lugar de un date. Esto ocurre porque Python’s timedelta se convierte a SQL INTERVAL, y la operación SQL date +/- interval devuelve un timestamp en estas bases de datos.
Para asegurarte de obtener un resultado de tipo date, utiliza uno de los siguientes enfoques. O bien, explícitamente convierte el resultado a una fecha:
import datetime
from django.db.models import DateField, F
from django.db.models.functions import Cast
qs = MyModel.objects.annotate(
previous_day=Cast(
F("date_field") - datetime.timedelta(days=1),
output_field=DateField(),
)
)
O en PostgreSQL solo, utiliza aritmética entera para representar días
from django.db.models import DateField, ExpressionWrapper, F
qs = MyModel.objects.annotate(
previous_day=ExpressionWrapper(
F("date_field") - 1, # Subtract 1 day as integer
output_field=DateField(),
)
)
DateTimeField
-
class DateTimeField(auto_now=False, auto_now_add=False, **options)[fuente]
Una fecha y hora, representada en Python por una instancia de datetime.datetime. Acepta los mismos argumentos adicionales que DateField.
El widget de formulario predeterminado para este campo es un solo DateTimeInput. El administrador utiliza dos widgets de texto separados TextInput con atajos de JavaScript.
Advertencia
Siempre utiliza DateTimeField con una instancia de datetime.datetime.
Si tienes una instancia de datetime.date, se recomienda convertirla a datetime.datetime primero. Si no lo haces, DateTimeField utilizará la medianoche en el zona horaria por defecto para el componente de tiempo. Esto es cierto tanto para el almacenamiento como para la comparación. Para comparar la parte de fecha de un DateTimeField con una instancia de datetime.date, utiliza el date lookup.
DecimalField
-
class DecimalField(max_digits=None, decimal_places=None, **options)[fuente]
Un número decimal fijo de precisión, representado en Python por una instancia de Decimal. Valida la entrada utilizando DecimalValidator.
Los siguientes argumentos son requeridos:
-
DecimalField.max_digits
El número máximo de dígitos permitido en el número. Ten en cuenta que este número debe ser mayor o igual a decimal_places.
-
DecimalField.decimal_places
El número de decimales para almacenar con el número.
Por ejemplo, para almacenar números hasta 999.99 con una resolución de 2 decimales, utilizarías:
models.DecimalField(..., max_digits=5, decimal_places=2)
Y para almacenar números hasta aproximadamente un billón con una resolución de 10 decimales:
models.DecimalField(..., max_digits=19, decimal_places=10)
El widget de formulario predeterminado para este campo es NumberInput cuando localize es False o TextInput en caso contrario.
DurationField
-
class DurationField(**options)[fuente]
Un campo para almacenar períodos de tiempo - modelado en Python por timedelta. Cuando se utiliza en PostgreSQL, el tipo de datos utilizado es interval y en Oracle el tipo de datos es INTERVAL DAY(9) TO SECOND(6). De lo contrario, se utiliza un bigint de microsegundos.
Nota
La aritmética con DurationField funciona en la mayoría de los casos. Sin embargo, al comparar el valor de un campo DurationField con la aritmética en instancias de DateTimeField no funcionará como se espera en todas las bases de datos excepto PostgreSQL.
Campo de correo electrónico
-
class EmailField(max_length=254, **options)[fuente]
Un CharField que verifica que el valor es una dirección de correo electrónico válida utilizando EmailValidator.
Campo de archivo
-
class FileField(upload_to='', storage=None, max_length=100, **options)[fuente]
Un campo de subida de archivo.
Nota
El argumento primary_key no está soportado y lanzará un error si se utiliza.
Tiene los siguientes argumentos opcionales:
-
FileField.upload_to
Esta atributo proporciona una forma de establecer el directorio de carga y nombre del archivo, y puede ser configurado de dos maneras. En ambos casos, el valor se pasa al método Storage.save().
Si especificas un valor de cadena o un Path, puede contener formateo con strftime(), que se reemplazará por la fecha/hora de carga del archivo (para evitar que los archivos cargados llenen el directorio dado). Por ejemplo:
class MyModel(models.Model):
# file will be uploaded to MEDIA_ROOT/uploads
upload = models.FileField(upload_to="uploads/")
# or...
# file will be saved to MEDIA_ROOT/uploads/2015/01/30
upload = models.FileField(upload_to="uploads/%Y/%m/%d/")
Si estás utilizando el almacenamiento por defecto FileSystemStorage, el valor de cadena se agregará a tu MEDIA_ROOT ruta para formar la ubicación en el sistema de archivos local donde los archivos cargados se almacenarán. Si estás utilizando un almacenamiento diferente, consulta la documentación de ese almacenamiento para ver cómo maneja upload_to.
upload_to también puede ser una función llamable, como una función. Esta será llamada para obtener el camino de carga, incluido el nombre del archivo. Esta función debe aceptar dos argumentos y devolver un camino Unix-style (con barras diagonales) que se pasará al sistema de almacenamiento. Los dos argumentos son:
Argumento |
Descripción |
|---|
instance
|
Una instancia del modelo donde se define el campo FileField. De manera más específica, es la instancia particular donde se está cargando actualmente el archivo.
En la mayoría de los casos, este objeto no habrá sido guardado en la base de datos aún, por lo que si utiliza el campo AutoField predeterminado, no tendrá un valor para su campo de clave primaria.
|
nombre del archivo
|
El nombre de archivo que se le dio originalmente al archivo. Esto puede o no tener en cuenta cuando se determina el camino final de destino. |
Por ejemplo:
def user_directory_path(instance, filename):
# file will be uploaded to MEDIA_ROOT/user_<id>/<filename>
return "user_{0}/{1}".format(instance.user.id, filename)
class MyModel(models.Model):
upload = models.FileField(upload_to=user_directory_path)
-
FileField.storage
Un objeto de almacenamiento, o una función que devuelve un objeto de almacenamiento. Maneja el almacenamiento y recuperación de tus archivos. Consulte la documentación Gestión de archivos para obtener detalles sobre cómo proporcionar este objeto.
El widget de formulario predeterminado para este campo es un ClearableFileInput.
Utilizar un FileField o un ImageField (consulte a continuación) en un modelo requiere unos pocos pasos:
En tu archivo de configuración, necesitarás definir MEDIA_ROOT como el camino completo a un directorio donde deseas que Django almacene los archivos subidos. (Para rendimiento, estos archivos no se almacenan en la base de datos.) Define MEDIA_URL como la URL pública base de ese directorio. Asegúrate de que este directorio sea writable por el usuario del servidor web.
Agrega el FileField o el ImageField a tu modelo, definiendo la opción upload_to para especificar un subdirectorio de MEDIA_ROOT para usar para los archivos subidos.
Todo lo que se almacenará en tu base de datos es una ruta al archivo (relativa a MEDIA_ROOT). Es probable que desees utilizar la conveniencia url proporcionada por Django. Por ejemplo, si tu campo ImageField se llama mug_shot, puedes obtener el camino absoluto a tu imagen en un template con {{ object.mug_shot.url }}.
Por ejemplo, supongamos que has establecido MEDIA_ROOT en '/home/media', y upload_to está configurado para 'photos/%Y/%m/%d'. La parte '%Y/%m/%d' de upload_to es formateo con strftime(); '%Y' es el año de cuatro dígitos, '%m' es el mes de dos dígitos y '%d' es el día de dos dígitos. Si subes un archivo el 15 de enero de 2007, se guardará en el directorio /home/media/photos/2007/01/15.
Si deseas recuperar el nombre del archivo en disco subido o el tamaño del archivo, podrías utilizar las propiedades name y size respectivamente; para obtener más información sobre las propiedades y métodos disponibles, consulta la referencia de clase File y la guía de temas Gestión de archivos.
Nota
El archivo se guarda como parte de la guardado del modelo en la base de datos, por lo que el nombre de archivo real utilizado en disco no puede confiarse hasta después de que el modelo haya sido guardado.
La URL relativa del archivo subido se puede obtener utilizando el atributo url. Internamente, esto llama al método url() del almacenamiento subyacente Storage.
Ten en cuenta que siempre que trates con archivos subidos, debes prestar mucha atención a dónde los estás subiendo y qué tipo de archivos son, para evitar agujeros de seguridad. Valida todos los archivos subidos para asegurarte de que los archivos son lo que crees que son. Por ejemplo, si permites que alguien suba archivos sin validación a un directorio dentro del ámbito del servidor web, entonces alguien podría subir un script CGI o PHP y ejecutar ese script visitando su URL en tu sitio. No permitas eso.
También ten en cuenta que incluso un archivo HTML subido, ya que puede ser ejecutado por el navegador (aunque no por el servidor), puede suponer amenazas de seguridad equivalentes a ataques XSS o CSRF.
Las instancias de FileField se crean en tu base de datos como columnas varchar con una longitud máxima predeterminada de 100 caracteres. Al igual que con otros campos, puedes cambiar la longitud máxima utilizando el argumento max_length.
FileField y FieldFile
-
class FieldFile[fuente]
Cuando accedes a un FileField en un modelo, se te da una instancia de FieldFile como proxy para acceder al archivo subyacente.
La API de FieldFile refleja la de File, con una diferencia clave: El objeto envuelto por la clase no es necesariamente un envoltorio alrededor del objeto de archivo incorporado de Python. En su lugar, es un envoltorio alrededor del resultado del método Storage.open(), que puede ser un objeto File o una implementación personalizada del API de File.
Además de la API heredada de File como read() y write(), FieldFile incluye varios métodos que se pueden utilizar para interactuar con el archivo subyacente:
Advertencia
Dos métodos de esta clase, save() y delete(), tienen por defecto a guardar el objeto modelo asociado del FieldFile en la base de datos.
-
FieldFile.name
El nombre del archivo incluyendo la ruta relativa desde la raíz del Storage asociado al campo FileField.
-
FieldFile.path[fuente]
Una propiedad de solo lectura para acceder a la ruta de sistema de archivos local del archivo llamando el método path() del almacenamiento subyacente Storage.
-
FieldFile.size[fuente]
El resultado del método Storage.size() del almacenamiento subyacente.
-
FieldFile.url[fuente]
Una propiedad de solo lectura para acceder a la URL relativa del archivo llamando el método url() del almacenamiento subyacente Storage.
-
FieldFile.open(mode='rb')[fuente]
Abre o vuelve a abrir el archivo asociado con esta instancia en la especificada mode. A diferencia del método estándar de Python open(), no devuelve un descriptor de archivo.
Dado que el archivo subyacente se abre implícitamente al acceder a él, puede ser innecesario llamar a este método excepto para resetear el puntero al archivo subyacente o cambiar la mode.
-
FieldFile.close()[fuente]
Se comporta como el método estándar de Python file.close() y cierra el archivo asociado con esta instancia.
-
FieldFile.save(name, content, save=True)[fuente]
Este método toma un nombre de archivo y contenido del archivo y los pasa a la clase de almacenamiento para el campo, luego asocia el archivo almacenado con el campo del modelo. Si deseas asociar manualmente datos de archivos con instancias de FileField en tu modelo, se utiliza el método save() para persistir esos datos de archivo.
Toma dos argumentos requeridos: name que es el nombre del archivo, y content que es un objeto conteniendo los contenidos del archivo. El argumento opcional save controla si se guarda la instancia del modelo después de que el archivo asociado con este campo ha sido modificado. Por defecto es True.
Ten en cuenta que el argumento content debe ser una instancia de django.core.files.File, no un objeto de archivo de Python incorporado. Puedes construir un File a partir de un objeto de archivo de Python existente como se muestra aquí:
from django.core.files import File
# Open an existing file using Python's built-in open()
f = open("/path/to/hello.world")
myfile = File(f)
Puedes construirla desde una cadena de Python como esta:
from django.core.files.base import ContentFile
myfile = ContentFile("hello world")
Para más información, vea:doc:/topics/files.
-
FieldFile.delete(save=True)[fuente]
Elimina el archivo asociado con esta instancia y elimina todos los atributos del campo. Nota: Este método cerrará el archivo si sucede a ser abierto cuando se llama delete().
El argumento opcional save controla si se guarda o no la instancia del modelo después de que el archivo asociado con este campo haya sido eliminado. Por defecto, es True.
Ten en cuenta que cuando se elimina un modelo, los archivos relacionados no se eliminan. Si necesitas limpiar archivos huérfanos, deberás manejarlo tú mismo (por ejemplo, mediante una orden de gestión personalizada que puede ejecutarse manualmente o programada para ejecutarse periódicamente a través de e.g. cron).
FilePathField
-
class FilePathField(path='', match=None, recursive=False, allow_files=True, allow_folders=False, max_length=100, **options)[fuente]
Un campo de caracteres (CharField) cuyas opciones están limitadas a los nombres de archivo en un directorio específico del sistema de archivos. Tiene algunas argumentos especiales, de los cuales el primero es obligatorio.
-
FilePathField.path
Requerido. La ruta de sistema de archivos absoluta a un directorio desde el que este campo de archivo de ruta (FilePathField) debería obtener sus opciones. Ejemplo: "/home/images".
path también puede ser una función llamable, como una función para establecer dinámicamente el camino en tiempo de ejecución. Ejemplo:
import os
from django.conf import settings
from django.db import models
def images_path():
return os.path.join(settings.LOCAL_FILE_DIR, "images")
class MyModel(models.Model):
file = models.FilePathField(path=images_path)
-
FilePathField.match
Opcional. Una expresión regular, como una cadena de texto, que FilePathField utilizará para filtrar nombres de archivo. Tenga en cuenta que la regex se aplicará al nombre de archivo base, no al camino completo. Ejemplo: "foo.*\.txt$", que coincidirá con un archivo llamado foo23.txt pero no bar.txt o foo23.png.
-
FilePathField.recursive
Opcional. Puede ser True o False. Por defecto es False. Especifica si se deben incluir todas las subcarpetas de path
-
FilePathField.allow_files
Optional. Opcional. Ya sea True o False. Por defecto es True. Especifica si los archivos en la ubicación especificada deben incluirse. Ya sea esta opción o allow_folders debe ser True.
-
FilePathField.allow_folders
Opcional. Ya sea True o False. Por defecto es False. Especifica si los directorios en la ubicación especificada deben incluirse. Ya sea esta opción o allow_files debe ser True.
El único potencial problema es que match se aplica al nombre de archivo base, no a la ruta completa. Por lo tanto, este ejemplo:
FilePathField(path="/home/images", match="foo.*", recursive=True)
…seleccionará /home/images/foo.png pero no /home/images/foo/bar.png porque match se aplica al nombre de archivo base (foo.png y bar.png).
Instancias de la clase FilePathField se crean en su base de datos como columnas varchar con una longitud máxima predeterminada de 100 caracteres. Al igual que con otros campos, puede cambiar la longitud máxima utilizando el argumento max_length.
FloatField
-
class FloatField(**options)[fuente]
Un número flotante representado en Python por una instancia de float.
El widget de formulario predeterminado para este campo es NumberInput cuando localize es False o TextInput en caso contrario.
FloatField vs. DecimalField
La clase FloatField a veces se confunde con la clase DecimalField. Aunque ambos representan números reales, los representan de manera diferente. FloatField utiliza el tipo float de Python internamente, mientras que DecimalField utiliza el tipo Decimal de Python. Para obtener información sobre la diferencia entre las dos, consulte la documentación de Python para el módulo decimal.
GeneratedField
-
class GeneratedField(expression, output_field, db_persist=None, **kwargs)[fuente]
Un campo que siempre se calcula en función de otros campos del modelo. Este campo está gestionado y actualizado por la base de datos misma. Utiliza la sintaxis SQL GENERATED ALWAYS.
Hay dos tipos de columnas generadas: almacenadas y virtuales. Una columna generada almacenada se calcula cuando se escribe (se inserta o actualiza) y ocupa espacio de almacenamiento como si fuera una columna regular. Una columna generada virtual no ocupa espacio de almacenamiento y se calcula cuando se lee. Por lo tanto, una columna generada virtual es similar a una vista y una columna generada almacenada es similar a una vista materializada.
-
GeneratedField.expression
Un Expression utilizado por la base de datos para establecer automáticamente el valor del campo cada vez que se modifica el modelo.
Las expresiones deben ser determinísticas y solo referenciar campos dentro del modelo (en la misma tabla de la base de datos). Las columnas generadas no pueden referenciar otras columnas generadas. Los backends de bases de datos pueden imponer restricciones adicionales.
-
GeneratedField.output_field
Una instancia de campo de modelo para definir el tipo de dato del campo.
-
GeneratedField.db_persist
Determina si la columna de la base de datos debe ocupar espacio de almacenamiento como si fuera una columna real. Si False, la columna actúa como una columna virtual y no ocupa espacio de almacenamiento en la base de datos.
Sólo PostgreSQL admite columnas persistidas. Sólo Oracle admite columnas virtuales.
Refrescar los datos
Dado que la base de datos calcula el valor, el objeto debe ser recargado para acceder al nuevo valor después de save(), por ejemplo, utilizando refresh_from_db().
Limitaciones de la base de datos
Hay muchas restricciones específicas de la base de datos sobre campos generados que Django no valida y la base de datos puede levantar un error. Por ejemplo, PostgreSQL requiere que las funciones y operadores referenciados en una columna generada estén marcados como IMMUTABLE.
You siempre debes comprobar que expression está soportado en tu base de datos. Consulta los documentos de MariaDB, MySQL, Oracle, PostgreSQL o SQLite.
GenericIPAddressField
-
class GenericIPAddressField(protocol='both', unpack_ipv4=False, **options)[fuente]
Una dirección IPv4 o IPv6, en formato de cadena (por ejemplo, 192.0.2.30 o 2a02:42fe::4). El widget de formulario por defecto para este campo es un TextInput.
La normalización de direcciones IPv6 sigue la RFC 4291 Section 2.2 sección 2.2, incluyendo el uso del formato IPv4 sugerido en el párrafo 3 de esa sección, como ::ffff:192.0.2.0. Por ejemplo, 2001:0::0:01 se normalizaría a 2001::1, y ::ffff:0a0a:0a0a a ::ffff:10.10.10.10. Todos los caracteres se convierten a minúsculas.
-
GenericIPAddressField.protocol
Limita los valores de entrada válidos al protocolo especificado. Los valores aceptados son 'both' (por defecto), 'IPv4' o 'IPv6'. El matching es insensible a mayúsculas y minúsculas.
-
GenericIPAddressField.unpack_ipv4
Desempaca direcciones IPv4 mapeadas como ::ffff:192.0.2.1. Si esta opción está habilitada, esa dirección se desempacaría a 192.0.2.1. El valor por defecto es deshabilitado. Solo puede usarse cuando protocol está configurado en 'both'.
Si permites valores en blanco, debes permitir valores nulos ya que los valores en blanco se almacenan como nulos.
ImageField
-
class ImageField(upload_to=None, height_field=None, width_field=None, max_length=100, **options)[fuente]
Hereda todas las atributos y métodos de FileField, pero también valida que el objeto subido sea una imagen válida.
Además de las atributos especiales disponibles para FileField, un campo ImageField también tiene los atributos height y width.
Para facilitar la consulta sobre esos atributos, el campo ImageField tiene los siguientes argumentos opcionales:
-
ImageField.height_field
Nombre de un campo de modelo que se auto-población con la altura de la imagen cada vez que se establece un objeto de imagen.
-
ImageField.width_field
Nombre de un campo de modelo que se auto-población con el ancho de la imagen cada vez que se establece un objeto de imagen.
Requiere la biblioteca pillow.
Campo de imagen se crean en tu base de datos como columnas varchar con una longitud máxima predeterminada de 100 caracteres. Al igual que otros campos, puedes cambiar la longitud máxima utilizando el argumento max_length.
El widget de formulario predeterminado para este campo es un ClearableFileInput.
IntegerField
-
class IntegerField(**options)[fuente]
Un entero. Solo se permiten valores entre ciertos puntos (dependientes del motor de base de datos). Los valores desde -2147483648 a 2147483647 son compatibles en todos los motores de bases de datos admitidos por Django.
Utiliza MinValueValidator y MaxValueValidator para validar la entrada según los valores que admite el motor de base de datos predeterminado.
El widget de formulario predeterminado para este campo es NumberInput cuando localize es False o TextInput en caso contrario.
JSONField
-
class JSONField(encoder=None, decoder=None, **options)[fuente]
Un campo para almacenar datos codificados en JSON. En Python, los datos se representan en su formato nativo: diccionarios, listas, cadenas, números, booleanos y None.
JSONField está soportado en MariaDB, MySQL, Oracle, PostgreSQL y SQLite (con la extensión JSON1 habilitada).
-
JSONField.encoder
Una clase de codificador JSON opcional json.JSONEncoder para serializar tipos de datos no admitidos por el serializador JSON estándar (por ejemplo, datetime.datetime o UUID). Por ejemplo, puedes utilizar la clase DjangoJSONEncoder.
Por defecto utiliza json.JSONEncoder.
-
JSONField.decoder
Una clase de descodificador JSON opcional json.JSONDecoder para deserializar el valor recuperado desde la base de datos. El valor estará en el formato elegido por el codificador personalizado (generalmente una cadena). Tu deserialización puede necesitar tener en cuenta el hecho de que no puedes estar seguro del tipo de entrada. Por ejemplo, corres el riesgo de devolver un datetime que era realmente una cadena que solo sucedió coincidir con el formato elegido para datetime.
Por defecto utiliza json.JSONDecoder.
Para consultar JSONField en la base de datos, consulta Consultar JSONField.
Valor por defecto
Si le das al campo un default, asegúrate de que sea una función como el dict clase o una función que devuelve un objeto fresco cada vez. Utilizar incorrectamente un objeto mutable como default={} o default=[] crea un valor por defecto mutable compartido entre todas las instancias.
Usuarios de PostgreSQL
PostgreSQL tiene dos tipos de datos JSON nativos: json y jsonb. La principal diferencia entre ellos es cómo se almacenan y cómo se pueden consultar. El campo json de PostgreSQL se almacena como la representación original en cadena del JSON y debe ser decodificado en el vuelo cuando se consulta basado en claves. El campo jsonb se almacena basado en la estructura real del JSON lo que permite el índice. La contrapartida es un pequeño costo adicional al escribir en el campo jsonb. JSONField utiliza jsonb.
Usuarios de Oracle
La base de datos Oracle no admite almacenar valores JSON escalares. Solo se admiten objetos y arreglos JSON (representados en Python usando :py:clase:`dict` y :py:clase:`list`) .
PositiveBigIntegerField
-
class PositiveBigIntegerField(**options)[fuente]
Como una :clase:`PositiveIntegerField`, pero solo permite valores bajo un punto determinado (dependiente de la base de datos). Los valores desde 0 a 9223372036854775807 son compatibles en todas las bases de datos admitidas por Django.
PositiveIntegerField
-
class PositiveIntegerField(**options)[fuente]
Como una :clase:`IntegerField`, pero debe ser positivo o cero (0). Solo se permiten valores bajo un punto determinado (dependiente de la base de datos). Los valores desde 0 a 2147483647 son compatibles en todas las bases de datos admitidas por Django. El valor 0 es aceptado por razones de compatibilidad hacia atrás.
Campo de Campo Entero Positivo
-
class PositiveSmallIntegerField(**options)[fuente]
Como un Campo de Campo Entero Positivo, pero solo permite valores por debajo de un cierto (punto dependiente del base de datos) punto. Los valores desde 0 a 32767 son compatibles en todas las bases de datos admitidas por Django.
CampoSlug
-
class SlugField(max_length=50, **options)[fuente]
Slug es un término periodístico. Un slug es una etiqueta corta para algo, que contiene solo letras, números, guiones bajos o guiones. Se utilizan generalmente en URLs.
Como un Campo de Caracteres, puedes especificar max_length (lee la nota sobre la portabilidad de la base de datos y max_length en esa sección también). Si no se especifica max_length, Django utilizará una longitud por defecto de 50.
Implica establecer Campo.db_index a True.
A menudo es útil prellenar automáticamente un Campo de Slug basado en el valor de alguna otra variable. Puedes hacer esto automáticamente en la administración utilizando prepopulated_fields.
Utiliza validate_slug o validate_unicode_slug para la validación.
-
SlugField.allow_unicode
Si True, el campo acepta letras Unicode además de las letras ASCII. Por defecto es False.
Campo de Campo Entero Pequeño
-
class SmallAutoField(**options)[fuente]
Como un Campo de Campo Entero, pero solo permite valores por debajo de un cierto (punto dependiente del base de datos) límite. Los valores desde 1 a 32767 son compatibles en todas las bases de datos admitidas por Django.
SmallIntegerField
-
class SmallIntegerField(**options)[fuente]
Como una IntegerField, pero solo permite valores por debajo de un cierto (punto dependiente del base de datos) punto. Los valores desde -32768 hasta 32767 son compatibles en todas las bases de datos soportadas por Django.
TextField
-
class TextField(**options)[fuente]
Un campo de texto grande. El widget de formulario predeterminado para este campo es un Textarea.
Si especificas el atributo max_length, se reflejará en el widget de formulario auto-generado Textarea. Sin embargo, no se aplica a nivel del modelo o base de datos. Utiliza un CharField para eso.
-
TextField.db_collation
Opcional. El nombre de collación de la base de datos del campo.
Nota
Los nombres de collación no están estandarizados. Como tal, esto no será portátil entre múltiples backends de bases de datos.
Oracle
Oracle no soporta collaciones para un TextField.
TimeField
-
class TimeField(auto_now=False, auto_now_add=False, **options)[fuente]
Una fecha y hora, representada en Python por una instancia de datetime.time. Acepta las mismas opciones de auto-población que DateField.
El widget de formulario predeterminado para este campo es un TimeInput. El admin agrega algunas atajos de JavaScript.
Campo UUID
-
class UUIDField(**options)[fuente]
Un campo para almacenar identificadores únicos universales. Utiliza la clase UUID de Python. Cuando se utiliza en PostgreSQL y MariaDB 10.7+, almacena en un uuid datatype, de lo contrario en un char(32).
Los identificadores únicos universales son una buena alternativa a AutoField para primary_key. La base de datos no generará el UUID por ti, por lo que se recomienda utilizar default:
import uuid
from django.db import models
class MyUUIDModel(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
# other fields
Ten en cuenta que se pasa un llamable (sin paréntesis) a default, no una instancia de UUID.
Consultas en PostgreSQL y MariaDB 10.7+
Las consultas con iexact, contains, icontains, startswith, istartswith, endswith o iendswith en PostgreSQL no funcionan para valores sin guiones, porque PostgreSQL y MariaDB 10.7+ los almacenan en un datatype de uuid con guiones.