Quindi è abbastanza facile confondersi
quando si guarda per la prima volta i modelli di dati
, le migrazioni e il database stesso.
E quindi voglio passare attraverso questo in modo un po 'più dettagliato.
Quindi le makemigrations sono ciò che legge i
file models.py e
quindi crea quelle che vengono chiamate migrazioni.
E la cosa chiave è che questo è guidato
dall'elenco delle applicazioni in settings.py.
Quindi, se fai una cosa nuova e fai una nuova applicazione,
e modifichi il file dei modelli e provi a eseguire
una makemigrations e non vede
nulla di simile, cosa ha fatto?
Beh, hai modificato il tuo settings.py? Perché c'è
una cosa chiamata app installate nel tuo settings.py.
Ora, le migrazioni sono portabili tra i database.
Ciò significa che la migrazione
è una descrizione logica di
come dovrebbero apparire le tabelle e sono un'evoluzione.
Ciò che significano è come la prima versione
di questa tabella, dal
primo models.py quando le migrazioni sono state eseguite per la prima volta, è 001.
E poi se cambi models.py
ed esegui di nuovo una migrazione,
esamina le modifiche dalla
migrazione 001 a models.py e poi 002,
e poi 002 non è come cancellare tutto e ricominciare da capo,
è come, «Oh aspetta, hai appena aggiunto una colonna.
Andrò avanti e aggiungo quella colonna.» Ma
non l'ha fatto in un modo che sia SQL reale.
Quindi le migrazioni sono esse stesse
tipo Python e sono portabili attraverso i database, il
che significa che potresti
usare SQLite sul tuo computer, e in produzione
potresti usare MySQL, e
le migrazioni sono le stesse per
entrambi perché stanno solo dicendo:
«Ecco il , ecco i tipi,
ecco cosa dovrebbero essere.»
Ora, contrastalo con un comando di migrazione.
Il comando migrate legge
tutte le migrazioni e
quindi sa
a quale database sta parlando ed esegue i comandi SQL per creare
le tabelle necessarie e/o evolvere le tabelle necessarie.
Così sembra e dice oh, ecco
la prima migrazione, ecco la seconda migrazione,
ecco la terza migrazione. Farò la tabella,
cambierò la tabella, cambierò la tabella,
cambierò la tabella e
alla fine di tutta la migrazione,
la migrazione passa quindi attraverso
tutte le migrazioni e quindi ha
una tabella di database che riflette
la somma totale delle migrazioni,
che riflette anche il file models.py più recente.
Quindi e' un po' complesso.
Ha a che fare con la portabilità
del database e il fatto che vogliamo
separare le parti portatili di questo
dalle parti non portatili a questo.
Quindi, se guardate le makemigrations
ed ecco un
campione dj4e, il mio piccolo esempio,
ci sono un sacco di modelli lì dentro.
E se dai un'occhiata a tutto il models.py,
vedi che per ogni applicazione
nel progetto di campioni dj4e,
vedi un file models.py e questo è un
codice Python, che è classe, libro, bla, bla, bla.
Questo è molto portabile ed è così che
nel nostro codice Python, nel nostro codice Django,
vediamo il modello di database.
E quando si esegue la makemigration,
che produce questi file di migrazione e
sono solo in autos/migrations/001_initial.py, ecc
E così si vede alcuni di quelli che ho qui,
in realtà ce ne sono due.
Quindi ha fatto il primo
e poi devo aver cambiato il file dei modelli,
e poi ho eseguito di nuovo le makemigrations e ha registrato
come quel modello è cambiato
dalla prima versione del
file dei modelli alla seconda versione.
Puoi guardarli, ma non modificarli,
puoi controllarli in GitHub, ma non modificarli.
Ma dai un'occhiata. Sono una rappresentazione molto portatile.
Sembrano assomigliare al file models.py.
Non dovresti cambiarli,
dovresti generarli
con le makemigrazioni. E ancora,
quelli possono andare in GitHub.
Ora, la migrazione legge fondamentalmente
tutti quei file di migrazione e
non solo uno, ma se
c'è una sequenza di file di migrazione,
li applica tutti in ordine secondo necessità.
E se il database ha
applicato la prima e la seconda migrazione
ma non la terza,
lo sa e dice: «Sai una cosa,
ho intenzione di modificare questo database
che già esiste, che è già in esecuzione,
e quindi aggiungere una colonna o modificare
la larghezza di una colonna o qualunque cosa
tu abbia chiesto di essere fatto modificando il tuo models.py.»
Quindi, quando la migrazione è
terminata, si finisce con un sacco di tabelle
nel database e sono tutte basate sul
nome dell'applicazione e sul nome
del modello all'interno dell'applicazione.
E così da qualche parte qui dentro è bookone_book,
bookone_instance e bookone_lang.
Quelle sono tutte sedute li'.
E così questi sono tutti i tavoli. E
prima abbiamo dato un'occhiata a quei tavoli.
Ma questa è la migrazione che va
da tutte le piccole migrazioni diffuse in tutte
le applicazioni in questo progetto e quindi
mette insieme un database che ha tutte queste cose.
E continuo a dire che le migrazioni
sono tutte incentrate sull'evoluzione,
perché se dai un'occhiata qui,
vedi una piccola tabella chiamata
django_migrazioni e quello che Django sta facendo in
quella tabella django_migrazioni sta ricordando quale di
queste migrazioni sono già state applicate a
questo database così come sta attraversando le migrazioni
, dice: «Oh, eccone
uno che non è ancora fatto in questo database,
quindi devo modificare il database solo un po '.»
Quindi ricorda le migrazioni che sono state fatte.
È piuttosto affascinante e
in queste piccole applicazioni,
non abbiamo sempre bisogno di essere così intelligenti al riguardo.
Quindi a volte quello che vuoi fare è
come, «Sono confuso,
ho intenzione di rieseguire il makemigrate»,
perché non stai realmente eseguendo la produzione,
lo stai facendo più e più volte, in
modo da poter rieseguire il makemigrate.
E il modo in cui lo fai è
fondamentalmente semplicemente eliminare il file,
puoi eliminare questi file.
Cancellerei tutti quelli che iniziano con zero.
Se hai intenzione di rieseguire makemigrate,
basta rieseguire makemigrations,
eliminare tutti quelli che iniziano con zero
e questo è in applicazione,
migrazioni, e poi sbarazzarsi di tutti questi,
e quindi puoi rieseguire
makemigrations e
leggerà il tuo file models.py,
e poi eseguirà tutte
le operazioni necessarie per ricreare il file di migrazione.
Bene, ora non e' questo il database,
sono le istruzioni su come creare il database, ok?
Quindi è così che riesegui la makemigrate.
È possibile eseguire la migrazione da zero,
questo è in realtà più semplice.
Quindi puoi cancellare
le migrazioni per un'applicazione e l'ho fatto, ho
appena cancellato il bookone qui,
questo è quello che ho fatto e ricominciato
da capo, ma puoi cancellare tutte le migrazioni e tutto il database e tutto semplicemente
rimuovendo il file in
questo caso perché noi stai eseguendo SQLite,
basta cancellare il file
rm db.sqlite perché dopo la migrazione,
è lì che tutto finisce in quel file.
Quindi se lo cancelli, non c'e' piu'.
Ora, potresti aver creato un account amministratore o
qualcosa del genere e hai intenzione di cancellare anche quello.
Cancellerai i dati,
cancellerai i tavoli, e' tutto sparito.
Questa è una cosa che mi piace di SQLite,
rimuovi questo file ed è letteralmente tutto sparito.
E poi esegui di nuovo python3 manage.py
migra e legge
tutte le migrazioni e ti rende un
database vuoto bello, pulito e perfetto.
Quindi, se sei un po 'bloccato
e non hai paura di perdere i tuoi dati,
che nella maggior parte dei programmatori iniziali
va bene cancellare la tua cosa SQLite
ed eseguire nuovamente la migrazione.
Vai avanti e provalo.
Come ho detto, se hai creato un account amministratore
, beh, devi farlo di nuovo,
ma questo è il peggio che puoi fare,
almeno in queste applicazioni iniziali.
Quindi ora che abbiamo parlato di
come inventare un modello di dati,
come codificarlo in Django models.py,
come fare migrazioni e come
migrare cose e come creare un database da esso,
ora parleremo del tipo di
codice Python che puoi
eseguire per aggiornare questi modelli nel database.
[ MUSIC]