Aplicando Migraciones para Modelos Propios

📐 De los Planos a la Realidad: Creando la Tabla en la Base de Datos

¡Excelente trabajo! Ya definimos nuestro modelo Proveedor en el archivo models.py y registramos nuestra app libreta en settings.py. Podríamos pensar que nuestra tabla de proveedores ya está lista en la base de datos, ¿verdad?

¡Pues no exactamente! Lo que hicimos fue darle a Django los "planos" de cómo queremos que sea nuestra tabla. Pero todavía no le hemos dicho "¡Construye la tabla según estos planos!".

Si intentaras interactuar con la tabla Proveedor en este momento (por ejemplo, desde el panel de administración, si ya la hubiéramos registrado ahí), Django te daría un error porque la tabla física aún no existe en el archivo db.sqlite3.

Nuestro models.py es el plano. Las migraciones son el proceso de construcción.

Este es un punto crucial en Django: cada vez que haces un cambio en la estructura de tus modelos (crear un nuevo modelo, agregar un campo a uno existente, modificar un campo, eliminarlo), necesitas decirle a Django que "actualice" la base de datos para que refleje esos cambios. Este proceso se llama migraciones.

🤕 Sin Django, Sería un Dolor de Cabeza...

Imagina que no estuviéramos usando Django. Cada vez que quisiéramos cambiar algo en nuestra base de datos, tendríamos que:

1. Conectarnos directamente a la base de datos (usando alguna herramienta especial).
2. Escribir comandos SQL (el lenguaje de las bases de datos) para crear la tabla, agregar la nueva columna, etc.
3. Asegurarnos de no cometer errores, ¡porque un error en SQL podría romper nuestra base de datos!

Suena complicado, ¿verdad? ¡Y lo es!

🦸 Django al Rescate: El Proceso de Migraciones en Dos Pasos

Afortunadamente, Django y su ORM nos simplifican enormemente este proceso con un sistema de migraciones de dos pasos. Django es tan inteligente que primero revisa los "planos" (nuestro models.py), los compara con el estado actual de la base de datos, prepara las "instrucciones de construcción" (en lenguaje SQL, pero no necesitamos verlo), y luego, cuando le damos el OK, ejecuta esas instrucciones para construir o modificar las tablas.

Este proceso de dos pasos nos da una capa extra de seguridad: podemos ver qué cambios va a hacer Django antes de que realmente toque la base de datos.

Paso 1: Preparando los Planos de Construcción (makemigrations)

El primer comando que vamos a usar es makemigrations. Este comando le dice a Django: "Oye, echa un vistazo a mis archivos models.py (de todas mis apps registradas) y fíjate si hay algún cambio nuevo que no se haya reflejado todavía en los archivos de migración".

Si Django encuentra cambios (como nuestro nuevo modelo Proveedor), generará un nuevo archivo de migración. Este archivo es como el conjunto de instrucciones detalladas (escritas en un formato que Django entiende, que luego traducirá a SQL) sobre cómo crear o modificar la tabla.

Ejecuta esto en tu terminal, dentro de la carpeta raíz de tu proyecto:

python manage.py makemigrations

Si todo va bien, Django te dirá algo como:

Migrations for 'libreta':
  libreta/migrations/0001_initial.py
    - Create model Proveedor

¡Excelente! Esto significa que Django detectó nuestro nuevo modelo Proveedor en la app libreta y creó un archivo de migración llamado 0001_initial.py dentro de la carpeta libreta/migrations/. Este archivo contiene las instrucciones para crear la tabla Proveedor.

Importante: Si cometes un error en la definición de tu modelo en models.py (por ejemplo, olvidas un max_length en un CharField), el comando makemigrations probablemente te dará un error aquí mismo, antes de intentar tocar la base de datos. ¡Es una gran ayuda!

Paso 2: ¡A Construir! Aplicando los Cambios (migrate)

Ya tenemos el plano de construcción (el archivo de migración). Ahora necesitamos decirle a Django: "Ok, estoy de acuerdo con estos planos, ¡construye o modifica la base de datos!".

Para esto, usamos el comando migrate que ya conocimos antes. Este comando tomará todos los archivos de migración que no se hayan aplicado todavía (como nuestro 0001_initial.py) y ejecutará las instrucciones SQL necesarias en la base de datos.

Ejecuta:

python manage.py migrate

Deberías ver algo como:

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, libreta, sessions
Running migrations:
  Applying libreta.0001_initial... OK

¡El "OK" al lado de libreta.0001_initial es música para nuestros oídos! Significa que Django aplicó exitosamente la migración y nuestra tabla Proveedor (con los campos nombre, direccion, email, telefono, y el id automático) ¡ya existe en nuestra base de datos db.sqlite3!

Ahora sí, nuestra base de datos está al día con la definición de nuestro modelo Proveedor. Ya podemos empezar a pensar en cómo agregar y ver proveedores a través del panel de administración de Django.

El video de este capítulo te muestra en detalle cómo ejecutar estos dos comandos y qué sucede detrás de escena.

Con nuestra tabla Proveedor creada en la base de datos, el siguiente paso es hacerla visible y manejable desde el panel de administración de Django. ¡Vamos a ello!