Un fichero de prueba es una colección de archivos que contienen el contenido serializado de la base de datos. Cada fichero de prueba tiene un nombre único, y los archivos que lo componen pueden estar distribuidos en múltiples directorios, en múltiples aplicaciones.
Ver también
/cómo-inicializar-datos
Los fijadores se pueden generar mediante manage.py dumpdata <dumpdata>. También es posible generar fijadores personalizados utilizando directamente las herramientas de serialización </topics/serialization> o incluso escribiéndolos a mano.
Los fijadores se pueden utilizar para pre-poblar la base de datos con datos para pruebas:
class MyTestCase(TestCase):
fixtures = ["fixture-label"]
o proporcionar algunos datos iniciales <initial-data-via-fixtures> utilizando el comando loaddata:
django-admin loaddata <fixture label>
Django buscará en estos lugares los fijadores:
En el directorio fixtures de cada aplicación instalada
En cualquier directorio listado en la configuración FIXTURE_DIRS
En el camino literal nombrado por la carga de datos fija
Django cargará cualquier y todas las cargas de datos fijas que encuentre en estas ubicaciones que coincidan con los nombres de carga de datos proporcionados. Si la carga de datos fija tiene una extensión de archivo, solo se cargarán cargas de datos de ese tipo. Por ejemplo:
django-admin loaddata mydata.json
solo cargaría cargas de datos JSON llamadas mydata. La extensión de la carga de datos fija debe corresponder al nombre registrado de un serializador (por ejemplo, json o xml).
Si omites las extensiones, Django buscará todos los tipos disponibles de cargas de datos para encontrar una carga de datos que coincida. Por ejemplo:
django-admin loaddata mydata
buscaría cualquier tipo de carga de datos llamada mydata. Si un directorio de cargas de datos contenía mydata.json, esa carga de datos se cargaría como una carga de datos JSON.
Las cargas de datos fijas que se nombran pueden incluir componentes de directorio. Estos directorios se incluirán en el camino de búsqueda. Por ejemplo:
django-admin loaddata foo/bar/mydata.json
buscaría <app_label>/fixtures/foo/bar/mydata.json para cada aplicación instalada, <dirname>/foo/bar/mydata.json para cada directorio en FIXTURE_DIRS, y el camino literal foo/bar/mydata.json.
Se pueden especificar múltiples cargas de datos en la misma invocación. Por ejemplo:
django-admin loaddata mammals birds insects
o en una clase de caso de prueba:
class AnimalTestCase(TestCase):
fixtures = ["mammals", "birds", "insects"]
La orden en la que se cargan los fijos sigue el orden en el que están listados, ya sea cuando se utiliza el comando de gestión o cuando se enumeran en la clase de caso de prueba como se muestra arriba.
En estos ejemplos, todos los fijos llamados mammals de todas las aplicaciones (en el orden en que están definidas en INSTALLED_APPS) se cargarán primero. A continuación, se cargarán todos los fijos birds, seguidos de todos los fijos insects.
Ten en cuenta que si el motor de base de datos admite restricciones a nivel de fila, estas restricciones se comprobarán al final de la transacción. Cualquier relación entre fijos puede dar lugar a un error de carga si la configuración de la base de datos no admite la verificación diferida de restricciones (consulte los docs de MySQL para un ejemplo).
Cuando se procesan los archivos de fijos, los datos se guardan en la base de datos tal como están. No se llaman los métodos definidos por el modelo save() y cualquier señal pre_save o post_save se llamará con raw=True ya que la instancia solo contiene atributos locales al modelo. Puede, por ejemplo, querer deshabilitar los manejadores que acceden a campos relacionados que no están presentes durante el cargado de fijos y que de lo contrario darían lugar a una excepción:
from django.db.models.signals import post_save
from .models import MyModel
def my_handler(**kwargs):
# disable the handler during fixture loading
if kwargs["raw"]:
return
...
post_save.connect(my_handler, sender=MyModel)
También podría escribir un decorador para encapsular esta lógica:
from functools import wraps
def disable_for_loaddata(signal_handler):
"""
Decorator that turns off signal handlers when loading fixture data.
"""
@wraps(signal_handler)
def wrapper(*args, **kwargs):
if kwargs["raw"]:
return
signal_handler(*args, **kwargs)
return wrapper
@disable_for_loaddata
def my_handler(**kwargs): ...
Solo ten en cuenta que esta lógica deshabilitará las señales siempre que se deserialicen los fijos, no solo durante loaddata.
Los fijos pueden estar comprimidos en formato zip, gz, bz2, lzma o xz. Por ejemplo:
django-admin loaddata mydata.json
buscaría cualquier de mydata.json, mydata.json.zip, mydata.json.gz, mydata.json.bz2, mydata.json.lzma o mydata.json.xz. El primer archivo contenido en un archivo comprimido se utiliza.
Los textos traducidos son:
MySQL con MyISAM y fijaciones
El motor de almacenamiento MyISAM de MySQL no soporta transacciones ni restricciones, por lo que si utilizas MyISAM, no obtendrás la validación de los datos de las fijaciones, o un rollback si se encuentran múltiples archivos de transacción.
Si estás en una configuración con varias bases de datos, es posible que tengas datos de fijaciones que quieras cargar en una base de datos pero no en otra. En esta situación, puedes agregar un identificador de base de datos a los nombres de tus fijaciones.
Por ejemplo, si tu configuración DATABASES tiene definida una base de datos users, nombra la fijación mydata.users.json o mydata.users.json.gz y la fijación solo se cargará cuando especifiques que quieras cargar datos en la base de datos users.
may 31, 2026