Por lo tanto, es bastante fácil confundirse
cuando mira por primera vez los modelos de datos
, las migraciones y la base de datos en sí.
Así que quiero pasar por esto con un poco más de detalle.
Entonces, las makemigrations es lo que lee los
archivos models.py y luego
crea lo que se llaman migraciones.
Y lo clave es que esto está guiado por
la lista de aplicaciones en settings.py.
Entonces, si haces algo nuevo y haces una nueva aplicación,
y editas el archivo de modelos e intentas ejecutar
un makemigrations y no ve
nada como, ¿qué acaba de hacer?
Bueno, ¿editaste tu settings.py? Porque hay
una cosa llamada aplicaciones instaladas en su settings.py.
Ahora, las migraciones son portátiles a través de bases de datos.
Esto significa que la migración
es una descripción lógica de cómo
deben verse las tablas y son una evolución.
Lo que significan es como la primera versión
de esta tabla, desde el
primer models.py cuando se ejecutaron las migraciones por primera vez, es 001.
Y luego, si cambia models.py
y ejecuta una migración de nuevo,
mira los cambios de
la migración 001 a models.py y luego 002,
y luego 002 no es como borrarlo todo y comenzar de nuevo,
es como, «Oh, espera, acabas de agregar una columna.
Seguiré adelante y añadiré esa columna». Pero
no lo ha hecho de una manera que sea SQL real.
Por lo tanto, las migraciones son
como Python y son portátiles a través de bases de datos,
lo que significa que en
su computadora puede usar SQLite, y en producción
puede usar MySQL, y
las migraciones son las mismas para
ambos porque solo dicen:
«Aquí está el , aquí están los tipos,
esto es lo que se supone que deben ser».
Ahora, contrasta eso con un comando migrar.
El comando migrate lee
todas las migraciones y
luego sabe con qué base de datos está hablando
y ejecuta los comandos SQL para crear
las tablas necesarias y/o evolucionar las tablas necesarias.
Así que parece y dice oh, aquí está
la primera migración, aquí está la segunda migración,
aquí está la tercera migración. Haré la tabla,
cambiaré la tabla, cambiaré la tabla,
cambiaré la tabla, y al
final de toda la migración,
la migración pasa a través de
todas las migraciones y luego tiene
una tabla de base de datos que refleja
la suma total de las migraciones,
que también refleja el último archivo models.py.
Así que es un poco complejo.
Tiene que ver con la portabilidad de
la base de datos y el hecho de que queremos
separar las partes portátiles de esto
de las partes no portátiles a esto.
Así que si nos fijamos en las migraciones maestras
y aquí hay muestras de dj4e,
mis pequeñas cosas de muestra,
hay un montón de modelos allí.
Y si echas un vistazo a todo el models.py,
ves que para cada aplicación
en el proyecto de muestras dj4e,
ves un archivo models.py y ese es un
código Python, eso es clase, libro, bla, bla, bla.
Eso es muy portátil y así es como
en nuestro código Python, en nuestro código Django,
vemos el modelo de base de datos.
Y cuando ejecutas la makemigration,
que produce estos archivos de migraciones y
están como autos/migrations/001_initial.py, etc.
Y entonces ves algunos de los que tengo aquí,
en realidad hay dos de ellos.
Así que hizo el primero
y luego debo haber cambiado el archivo de modelos,
y luego volví a ejecutar makemigrations y registró
cómo ese modelo cambió de
la primera versión del
archivo de modelos a la segunda versión.
Puedes verlos, pero no los edites,
puedes registrarlos en GitHub, pero no los edites.
Pero échale un vistazo. Son una representación muy portátil.
Se parecen al archivo models.py.
No se supone que los cambies,
se supone que los genera
con makemigraciones. Y de nuevo,
esos pueden entrar en GitHub.
Ahora, la migración básicamente lee
todos esos archivos de migración y
no solo uno, pero si
hay una secuencia de archivos de migración,
los aplica todos en orden según sea necesario.
Y si la base de datos tiene
aplicada la primera y
la segunda migración, pero no la tercera,
lo sabe y dice: «Sabes qué,
voy a ajustar esta base de datos
que ya existe, que ya se está ejecutando,
y luego agregar una columna o cambiar
el ancho de una columna o sea lo
que sea que haya pedido que se haga editando su models.py.»
Entonces, cuando finaliza la migración,
terminas con un montón de tablas
en tu base de datos y todas se basan en
el nombre de la aplicación y el nombre
del modelo dentro de la aplicación.
Así que en algún lugar de aquí está bookone_book,
bookone_instance y bookone_lang.
Están todos sentados ahí.
Y esas son todas las mesas. Y
echamos un vistazo a esas mesas antes.
Pero esa es la migración que va
de todas las pequeñas migraciones diseminadas
en todas las aplicaciones de este proyecto y luego
crea una base de datos que tiene todas esas cosas.
Y sigo diciendo que las migraciones
son todo acerca de la evolución,
porque si miras aquí,
ves una pequeña tabla llamada
django_migrations y lo que Django está haciendo en
esa tabla django_migrations es recordar cuál de
esas migraciones ya se han aplicado a
esta base de datos para que a medida que está pasando por las migraciones
, dice: «Oh, aquí hay
una que aún no se ha hecho en esta base de datos,
así que tengo que ajustar la base de datos un poco».
Así que recuerda las migraciones que se han hecho.
Es bastante fascinante y
en estas pequeñas aplicaciones,
no siempre necesitamos ser tan inteligentes al respecto.
Así que a veces lo que quieres hacer es
como, «Estoy confundido,
voy a volver a ejecutar el makemigrate»,
porque realmente no estás ejecutando la producción,
lo estás haciendo una y otra vez,
para que puedas volver a ejecutar el makemigrate.
Y la forma en que lo haces es
básicamente simplemente eliminar el archivo,
puedes eliminar estos archivos.
Eliminaría todos los que comiencen con cero.
Si va a volver a ejecutar makemigrate,
simplemente vuelva a ejecutar makemigrations,
elimine todos los que comienzan con cero
y esto está en aplicación,
migraciones, y luego deshacerse de todos estos,
y luego puede volver a ejecutar
makemigraciones y
leerá su archivo models.py,
y luego hará todas
las cosas necesarias para volver a crear el archivo de migración.
Bien, ahora esa no es la base de datos,
esas son las instrucciones sobre cómo crear la base de datos, ¿de acuerdo?
Así es como vuelves a ejecutar makemigrar.
Puede ejecutar migrar desde cero,
esto es en realidad más fácil.
Así que puedes eliminar
las migraciones para una aplicación y lo hice,
acabo con el bookone aquí,
eso es lo que hice y comencé de nuevo,
pero puedes eliminar todas las migraciones y
toda la base de datos y todo simplemente
eliminando el archivo en
este caso porque está ejecutando SQLite,
simplemente elimine el archivo
rm db.sqlite porque después de migrar,
ahí es donde todo termina está en ese archivo.
Así que luego borras eso, se ha ido.
Ahora, es posible que hayas creado una cuenta de administrador o
algo así y también vas a eliminar eso.
Vas a borrar los datos,
vas a borrar las mesas, todo se ha ido.
Esa es una cosa que me gusta de SQLite,
eliminas este archivo y literalmente todo se ha ido.
Y luego vuelve a ejecutar python3 manage.py
migrar y lee
todas las migraciones y te hace una
base de datos vacía agradable, limpia y perfecta.
Entonces, si estás un poco atascado
y no tienes miedo de perder tus datos,
que en la mayoría de los programadores principiantes
está bien eliminar tu cosa SQLite
y ejecutar migrar de nuevo.
Adelante y pruébalo.
Como dije, si creaste una cuenta de administrador
, bueno, tienes que hacerlo de nuevo,
pero eso es lo peor que puedes hacer,
al menos en estas aplicaciones iniciales.
Así que ahora que hemos hablado sobre
cómo crear un modelo de datos,
cómo codificarlo en Django models.py,
cómo hacer migraciones, y cómo
migrar cosas y cómo hacer una base de datos a partir de él,
ahora vamos a hablar sobre el tipo de
código Python que puede
ejecutar para actualizar estos modelos en la base de datos.
[ MÚSICA]