Aprender a ejecutar migraciones en Django es el paso que conecta tus modelos de Python con las tablas reales de la base de datos. Si trabajas con el framework y aún ves el mensaje de unapplied migrations al levantar el servidor, esta guía te muestra el flujo exacto: desde makemigrations hasta verificar la tabla creada en SQLite.

¿Qué significa el mensaje de migraciones no aplicadas en Django?

Cuando ejecutas python manage.py runserver y aparece la advertencia de 18 migraciones pendientes, Django te avisa que tus modelos todavía no tienen una tabla equivalente en la base de datos. Tu proyecto puede arrancar, pero fallará al intentar leer o escribir datos.

Django incluye baterías incluidas: trae módulos como autenticación que ya definen sus propias tablas. Esas migraciones existen aunque tú no las hayas escrito, y se aplican con un solo comando.

¿Qué hace el comando migrate en Django? Toma todas las migraciones registradas, tanto las internas de Django como las tuyas, y crea o actualiza las tablas correspondientes en la base de datos configurada [01:00].

¿Cómo crear una migración para un modelo propio?

Partiendo del modelo Car definido en clases anteriores, el flujo se resume en dos pasos. Primero generas el archivo de migración, luego lo aplicas.

Paso 1: generar la migración con makemigrations

El comando python manage.py makemigrations revisa tus modelos y crea un archivo nuevo dentro de la carpeta migrations de la app. En el ejemplo, Django genera el archivo 0001_initial.py para la app MyFirstApp y reporta que se creó el modelo Car [01:45].

Dentro de ese archivo encontrarás una clase con operaciones. La operación principal es CreateModel, que describe la estructura que se enviará a la base de datos.

Paso 2: revisar lo que Django agregó automáticamente

Al abrir la migración notarás dos campos:

• Un campo id que Django añade por defecto como llave primaria.
• El campo title, que sí definiste en tu modelo.

El id es obligatorio para referenciar registros. Si necesitas cambiar su tipo de dato, puedes declararlo manualmente en la clase Car, pero para la mayoría de los casos el comportamiento por defecto es suficiente [02:30].

Paso 3: aplicar la migración

Ejecutas de nuevo python manage.py migrate y Django mostrará el mensaje Applying MyFirstApp.0001_initial. En ese momento la tabla queda creada físicamente en la base de datos.

¿Dónde se guarda la base de datos por defecto en un proyecto Django?

La respuesta está en el archivo settings.py, dentro de la sección DATABASES. Es un diccionario con la clave default que apunta al motor que se usará si no defines otro.

¿Qué es SQLite y por qué Django lo usa por defecto? SQLite es una base de datos almacenada en un solo archivo, fácil de configurar y útil para desarrollo. No se recomienda en producción porque maneja poca concurrencia y puede generar colisiones cuando varios procesos escriben al mismo tiempo [03:30].

En el proyecto verás un archivo db.sqlite3 en la raíz. Esa es la base de datos donde quedaron tus tablas. La configuración del motor se lee así en settings:

• ENGINE: indica el motor, en este caso sqlite3.
• NAME: combina BASE_DIR con el nombre del archivo .sqlite3.

Otras configuraciones clave del archivo settings

Mientras revisas settings.py vale la pena ubicar otras variables que aparecen junto a la configuración de base de datos:

• SECRET_KEY: cifra información sensible del proyecto.
• DEBUG: activa mensajes de error detallados durante el desarrollo.
• ALLOWED_HOSTS: define qué dominios pueden servir tu aplicación, evitando que terceros apunten a tu servidor.
• INSTALLED_APPS: lista las apps internas de Django y las que tú agregas.
• MIDDLEWARE: capa intermedia entre la petición y la respuesta, con su propio tema dedicado.
• TEMPLATES: controla cómo se renderizan las vistas y qué información del request se expone.

¿Cómo verificar que la tabla se creó correctamente?

Django trae un cliente integrado para inspeccionar la base de datos sin instalar herramientas extra. El comando es python manage.py dbshell y abre una conexión directa al motor configurado [04:30].

Una vez dentro de la shell de SQLite puedes correr:

1. .tables para listar todas las tablas existentes.
2. .schema nombre_de_la_tabla para ver la definición exacta de columnas.

Al listar las tablas aparecerá my_first_app_car. Django nombra cada tabla concatenando el nombre de la app, un guion bajo y el nombre del modelo en minúscula. Esta convención evita colisiones cuando dos apps distintas tienen modelos con el mismo nombre.

¿Por qué Django pone el nombre de la app como prefijo en las tablas? Porque dos apps pueden tener modelos llamados igual. Sin el prefijo, ambas chocarían en la misma base de datos. Con él, cada tabla queda identificada de forma única [05:30].

Al ejecutar .schema my_first_app_car confirmas que la tabla tiene los campos id y title, idénticos a los descritos en la migración inicial.

¿Con qué bases de datos es compatible Django además de SQLite?

Django soporta varios motores listos para usar cambiando solo el bloque DATABASES en settings:

• PostgreSQL.
• MariaDB.
• MySQL.
• Oracle.
• SQLite.

Para proyectos reales, PostgreSQL suele ser la opción preferida por su robustez, manejo de concurrencia y soporte avanzado de tipos de datos. Cuenta a otros estudiantes en los comentarios qué motor estás usando en tus proyectos y por qué.