Ciao e benvenuti alla nostra lezione sui semplici modelli Django.
Ora, come avete visto nelle lezioni precedenti,
abbiamo parlato di SQL, Structured Query Language,
ed è così che parliamo con i database.
Ed è bello perché consente
la portabilità fino a un punto attraverso i database,
e abbiamo parlato di tutte le cose di creazione della tabella,
e quindi questo è solo un po 'di revisione
in cui possiamo digitare questi comandi su SQLite.
Eseguiamo SQLite, eseguiamo un'istruzione CREATE TABLE,
e lo facciamo.
E diciamo tabelle a puntini, quindi andiamo.
Possiamo chiedere che tipo di utenti schema.
Abbiamo fatto tutto questo in una lezione precedente.
E quindi è fondamentalmente così che funziona SQL.
Ed ecco una serie di comandi SQL da
una lezione precedente, solo come revisione.
E' piuttosto semplice, CRUD.
Ora, uno dei problemi, come ho detto, è che
diversi database come Postgres e
MySQL fanno tutte queste cose identiche.
Ma poi alcune cose più sottili
come funzionano le chiavi esterne,
che impareremo in un po ',
o come fanno limiti come tirare tipo 25, il prossimo 25, il
prossimo 25, il prossimo 25, questo è un po 'diverso.
E quindi se vuoi creare un'applicazione che
parli su più di un database,
devi pensare un po '.
E una soluzione a questo,
anche per limitare la fantasia SQL che devi imparare,
mi piace dire che
puoi imparare il primo 60 percento
di SQL in circa tre ore,
e l'ultimo 40 percento è letteralmente una vita.
SQL così avanzato è difficile da fare.
È davvero difficile insegnare una classe in SQL avanzato.
Posso insegnarti funzionalità avanzate,
ma poi ci sono così tante funzionalità che
non puoi imparare in una classe,
perché quale database stai usando,
sono diverse per ogni database.
Quindi una cosa che è successo nell'ultimo decennio o giù di
lì è l'emergere di quelli che vengono
chiamati mappatori relazionali a oggetti.
E cioè, hai il livello di database fisico,
e poi hai SQL,
che è un'astrazione,
è un'astrazione imperfetta.
E poi Django costruisce un'altra
astrazione su quel chiamato mapper relazionale a oggetti.
Quindi creiamo solo
un oggetto Python e chiediamo che venga inserito in una tabella.
Ora l'oggetto può avere un nome,
un indirizzo e-mail e un compleanno o qualcosa del genere.
Può avere tutti i tipi di dati in quell'oggetto,
e quindi che si mappa in un nome e un indirizzo e-mail.
E dobbiamo dirla come vogliamo che questo sia
indicizzato. E tutti questi altri tipi di cose che
comunichiamo attraverso l'ORM.
Quindi lasciamo l'ORM da solo.
Ora in Django, man mano che diventiamo più avanzati,
puoi anche aggirare l'ORM perché
il modo in cui gli oggetti sono mappati nelle tabelle è prevedibile.
I nomi delle colonne sono prevedibili.
E quindi è un po 'come se fosse una scorciatoia per
mi piace pensare che sia come l'80% delle
cose più comuni che fai
con il database sia facilmente
fatto con un modello relazionale a oggetti, oggetto ORM.
Ma alla fine, una volta arrivati alle cose più avanzate,
si tende a non essere in grado di farlo con un ORM.
Si arriva al punto in cui
scrivere l'SQL è più facile rispetto all'utilizzo dell'ORM.
Ma per circa l'80%,
scrivere codice ORM è molto più facile che scrivere l'SQL.
L' altra cosa che ORM fa
è che ti permette di avere
più database perché il codice ORM
all'interno di Django conosce
la differenza tra SQLite, Postgres e MySQL.
E così avresti potuto effettivamente avviare
un'applicazione che usa
SQLite durante tutto il tuo sviluppo,
e poi quando vai alla produzione,
vai, sai una cosa,
usiamo MySQL o Postgres invece.
Ed e' piuttosto figo.
Li trovo limitanti, e quindi voglio solo che tu
sappia sia come usare gli oggetti che come usare SQL.
Ma capisci che la maggior parte di quello che stai per
fare è usare la mappatura relazionale degli oggetti,
e otteniamo un sacco di potenza con questo.
Quindi, se guardiamo al modo in cui
comunichiamo al database o al
modo in cui definiamo il database,
in SQL creiamo una tabella,
e che proprio lì è portabile.
Ma una volta che inizi a fare cose come
aggiungere colonne di incremento automatico e cose del genere,
smette di essere portatile.
E questo è il modo in cui lo facciamo.
Ma in Django, il modo in cui lo
facciamo è che abbiamo un file chiamato models.py
ed è nella cartella dell'applicazione.
E poi useremo gli orientamenti degli oggetti.
Quindi da django.db, questo è un pacchetto,
stiamo andando a importare modelli, e modelli è ora una classe.
E stiamo andando a creare una classe chiamata User.
Questo sta per essere equivalente al nome della tabella,
e nella definizione,
stiamo andando ad estendere modelli.Model.
Quindi questo si chiama estensione, si chiama ereditarietà.
Otterremo molte
funzionalità e funzionalità da questo codice.
Quindi probabilmente ci sono 20.000 righe di codice fantasia che
non abbiamo scritto che stiamo usando.
Estendendo modelli.modello, stiamo ottenendo tutto questo.
E poi qui dentro, creiamo un paio di
attributi che in pratica dice,
dammi un campo di carattere.
è una classe,
CharField è un metodo all'interno di quella classe.
max_length è uguale a 128,
e questo ci dà il nome.
Queste due cose sono equivalenti.
E quello che succede è
quando costruiamo questo e
facciamo quello che viene chiamato eseguire una migrazione,
quindi Django creerà questa tabella per noi.
Ma poi abbiamo questa astrazione
che possiamo usare per parlarci.
Quindi questo è chiamato migrazione,
e quindi devi essere nella cartella progetti.
E così una volta creata una migrazione
all'interno della tua applicazione Django,
allora vai
nel progetto Django e dici, python3 manage.py.
Ora, manage.py è un po 'come la cosa che inizia tutto.
Quindi makemigrations sta effettivamente creando
file, perché l'idea con le migrazioni è che
eseguiresti il debug delle tue migrazioni
sul tuo ambiente di sviluppo,
e poi una volta che lo
sai, li sposterai in produzione.
Quindi faresti le migrazioni nell'ambiente di sviluppo, le
farai bene e poi vorresti
controllarle in GitHub, forse.
E poi in produzione, estrarresti le
tue migrazioni da GitHub e poi migreranno.
Quindi il bit di makemigrations,
che sta creando un insieme di script di migrazione,
e si può vedere che sta facendo
questi file e sono file reali,
e si può andare a trovare quei file come 001_initial.py.
E poi la migrazione sta leggendo
le migrazioni e poi effettivamente cambiando il database.
Quindi è quello in cui
potresti essere in grado di effettuare una migrazione
e non
importa quale database userai.
Potrebbe essere il tuo sviluppo in
SQLite e produzione in MySQL.
Faresti la migrazione
in entrambi questi, e il tuo sviluppo,
creerebbe un database SQLite, e nella tua produzione,
creerebbe un database MySQL e inserirebbe le tabelle.
E l'SQL potrebbe anche essere abbastanza sottile, e
sarà sottilmente diverso
tra loro, ma non ti interessa.
Quindi migrare è l'atto di creare il database.
Ora, nei nostri ambienti di sviluppo,
stiamo per creare un file chiamato db.sqlite3.
E quindi se ti incasini,
non devi rifare le tue migrazioni,
sono solo seduti lì come parte del tuo codice sorgente.
E puoi sbarazzarti del file db.sqlite3 e
quindi eseguire di nuovo le migrazioni se ti incasini.
Quindi le makemigrations
leggono questo e creano questi altri piccoli file.
Puoi dargli un'occhiata. Sono un po' come
i file interni di Django, sono Python.
È solo che non li scriverai da solo,
ma poi la migrazione legge 001_initial.py,
e quindi crea effettivamente
comandi SQL ed esegue quei comandi SQL per noi.
E quindi se saltiamo dopo aver fatto questo,
vediamo questo file db.sqlite3,
e possiamo saltare e dare un'occhiata.
Di nuovo, devi essere nella cartella giusta,
quindi saresti in django_projects
e quindi nella cartella del progetto.
Ma ci sarebbe un file chiamato db.sqlite3.
Vai in una riga di comando di Linux,
digita sqlite3, db.sqlite3,
e troverai un sacco di cose.
E quando entri in SQLite e digiti tabelle dot,
vedrai che Django ha un sacco
di migrazioni che sono
tutte lì dalle sessioni
e cose che impareremo come usare in seguito
, autorizzazione, ecc., Ma poi
il particolare modello di dati che hai creato,
che è un modello di dati utente,
c'è una tabella lì per questo.
E se usiamo il comando dello schema,
sqlite3, e diciamo, cosa c'è in
quella tabella usermodel_user,
si vede un'istruzione CREATE, giusto?
E così questa è l'effettiva dichiarazione CREATE che
Django ha inviato a SQLite per creare la tabella.
E parlavo di alcune
di queste cose sono abbastanza prevedibili.
Il nome della colonna è abbastanza prevedibile,
id, nome, e-mail, ecc
Si aggiunge il campo id per voi automaticamente.
E la maggior parte è portatile,
come questa parte qui è abbastanza portatile,
ma questa dichiarazione id qui,
PRIMARY KEY AUTOINCREMENT,
si scopre che se sei in MySQL,
o Oracle, o Postgres, o SQLite,
è un po 'diverso, ma letteralmente,
la migrazione si prende cura di tutto ciò
perché la migrazione conosce quella cosa,
e man mano che MySQL cambia,
quella particolare sintassi non cambia molto,
ma man mano che MySQL
cambia, la roba di Django cambia e tutto funziona.
E così puoi eseguire
questi comandi e poi sgattaiolare di nuovo nel database,
e puoi vedere cosa hanno fatto.
Ma è tutto molto prevedibile.
Non voglio rovesciare il caffe' sul computer.
Quindi stai parlando
al livello basso quando esegui il comando sqlite,
ma puoi anche essere in quella cartella,
la stessa cartella che ha db.sqlite e manage.py.
E poi puoi iniziare quello che viene chiamato shell.
Quindi questo è diverso dalla shell Linux,
e si vede il rapido cambiamento da
simbolo del dollaro a tre chevron.
E non è la stessa della shell Python,
anche se è la stessa della shell Python
con un sacco di
librerie Django premontate.
Quindi, se dici semplicemente python3,
otterrai questo ma questo comando successivo che è da
usermodel.models import User,
che fallirà a meno che non lasci che
manage.py inizi la tua shell perché di nuovo,
carica un sacco di oggetti e classi nel tuo spazio,
e poi all'improvviso usermodel.
funziona, l'utente è lì, ecc
Quindi questo sta tirando dal
tuo file models.py che hai costruito.
E così usermodel è il nome dell'applicazione
e i modelli sono il file models.py.
Importiamo il modello utente che è, in questo caso,
una classe, l'utente è una classe,
e stiamo andando a fare una chiamata costruttore.
E così diremo, facciamo un nuovo utente,
impostiamo il nome su Kristen e l'email su quella email.
E questo in realtà non ha fatto nulla nel database.
Questo crea, in effetti,
solo una variabile Python.
E poi per forzarlo a scrivere
nel database, chiamiamo u.save.
E quindi salva è un metodo su questo nuovo oggetto utente.
L' utente di capitale è una classe.
Stiamo usando un costruttore per
costruire dalla classe un'istanza effettiva,
un oggetto, e lo otteniamo in u, l'oggetto istanza.
E poi quell'oggetto si trova nella nostra memoria fino a quando diciamo salva,
e poi lo spinge anche di nuovo al database.
Ora, una delle cose che il salvataggio
fa, assegna, in effetti, un numero di serie o un id di riga.
Se guardate questi, iniziano abbastanza
prevedibilmente da 1, 2, 3, 4, 5.
Ma se stai ricevendo un sacco di cose
che arrivano da un mucchio di posti,
allora il database assegna solo ogni oggetto,
ogni riga, e questo fa parte di
quell'intera cosa di autoincremento.
Forza, torna su. Tutta questa storia dell'
autoincremento. Dice:
«Ehi, database, inserirò i record,
ti darò il nome e l'email,
e tu inventerai un numero, ma quando hai finito,
voglio che tu mi dica qual è il numero.»
Ed è così che si ottiene quel numero, dicendo print u.id.
Ora, se si
stampava u.id prima di fare il salvataggio, non esisterebbe.
E poi stampare u.email, puoi vedere che
questa email è solo i dati che abbiamo inserito, ma ora,
questo non è solo nella
tua variabile u, ma è anche nel database pure. Ok?
Ora, possiamo scavare
un po 'in come
questa mappatura relazionale oggetto funziona.
E quindi se sei nel mezzo
e stai facendo cose come quell'ultima affermazione,
puoi da django.db importare la connessione
e quindi chiedere connection.query.
E poi quello che fa, ti mostra solo un po 'di
dati di debug e cosa ha fatto,
come è iniziato, il fatto che ha eseguito un'istruzione INSERT.
E ancora, questo sembra un po' familiare.
Sta creando SQL per
te per quell'inserto, l'istruzione save,
quell'istruzione save lì.
Sta facendo quell'inserto per te
e poi puoi vedere cosa sta facendo, giusto?
E così questo salva, imposta una cosa e salvala.
Non è necessario conoscere INSERT INTO o qualsiasi altra cosa perché
il modello relazionale a oggetti lo fa per te, giusto?
E questo è una specie di quello che abbiamo fatto prima,
INSERT INTO utenti capitali, a mano.
E così di nuovo, troverai che questo ORM ti farà risparmiare
un sacco di tempo per
l'80% delle cose che fai con il database.
E così puoi fare
operazioni CRUD di base con questo mappatore relazionale a oggetti.
Il salvataggio è INSERT.
SELECT è fondamentalmente user.Object.Values.
Questo è come SELECT star, quindi dammi tutti gli oggetti.
Una clausola WHERE è user.Objects.Filter
e c'è la clausola WHERE.
email è un nome di colonna e
csev@umich.edu è un valore in quella colonna.
è in realtà andare a prenderli in modo da poter creare una sorta di query.
Quindi, se non si inseriscono valori,
si ottiene una sorta di query che non è ancora eseguita,
e quindi i valori dicono,
«Vai a farlo, fallo ora».
Puoi cancellare qualcosa in cui dici
Quindi questa è una sintassi leggermente diversa.
Questa è una specie di selettore che dice,
«Queste sono le righe da selezionare» e
quindi «Elimina quelle righe».
Questo valore dice, «Recupera le righe».
Elimina dice: «Sbarazzati delle righe».
E ancora, lo stesso tipo di cosa,
questo è un po 'come una clausola WHERE,
User.Objects.Filter email è uguale all'aggiornamento del punto csev@umich.edu,
e quindi cambia questa colonna in un modo,
e puoi andare a recuperare tutti i valori.
E ci sono cose che corrispondono a un sacco di
SQL, come darmi tutti questi valori,
ordine via e-mail, ecc, ecc, ecc
E 'una specie di mappatura uno-a-uno.
Ancora una volta, farai molta programmazione
usando questo ORM in Django,
e ogni tanto,
ti intrufolerai a SQL.
Ecco perché ti insegno prima l'SQL.
E ci sono molti
campi che potrebbero non essere
rappresentati esattamente allo stesso modo nel database.
Quindi, per esempio, un campo e-mail.
I database in genere non hanno campi di posta elettronica.
Potrebbero esserci alcuni database che contengono
email e altri no.
Ma poiché il mapper relazionale degli oggetti è
un livello tra te e il database, e tu dici,
«Mi piacerebbe che questo fosse un campo email», allora può aggiungere
regole e cose come il controllo della validità, ecc.,
Per dire, «Sai una cosa? Questo non
sembra un indirizzo email.»
E quindi ci sono tutte queste cose, e queste sono molto utili.
E più tardi, parleremo di
collegare le tabelle e useremo cose come
chiavi esterne e campi molti-a-molti e campi uno-a-uno,
e quelli sono meno sui dati e più sulle
connessioni tra tabelle di
cui parleremo presto.
E quindi solo per darvi una sorta di senso di dove vi trovate,
questa è la nostra applicazione, giusto?
E così abbiamo un browser sul lato sinistro
con un utente che fa qualche clic.
Ormai, potresti aver creato un file urls.py
e che prende la sintassi delle richieste GET,
barra questo, barra quello,
barra qualsiasi cosa e lo indirizza a
una vista particolare proveniente dal file views.py.
Potresti aver fatto o meno uno di quelli.
Modelli e moduli aiutano a produrre output.
Ma i modelli sono la nostra
interazione tra noi e il database.
E così il codice reale che scriviamo in Django
può parlare attraverso i modelli al database,
cosa che potresti non aver ancora fatto, ma questa shell sta parlando
anche attraverso i modelli Django al database.
E se stai iniziando a utilizzare l'interfaccia utente
admin, l'interfaccia utente admin
parla al database attraverso i modelli,
ed è informata dal tipo di cose
che aggiungi a admin.py.
Se vuoi usare l'interfaccia di amministrazione di Django
e hai mostrato il tuo modello in un modo particolare,
ha un sacco di valori predefiniti, ma spesso
vuoi sovrascrivere quei valori predefiniti
e quindi è quello che inserisci.
E il file model.py informa questa connessione tra
il database e
informa anche il tipo di codice che scrivi qui in un codice di visualizzazione,
in Python o nella shell Python,
che è una specie di shell Django, che è
una shell Python con tutte quelle cose aggiunte ad esso.
Ok, quindi questo model.py è fondamentale per
definire la nostra relazione tra tutto il nostro codice Python,
e l'interfaccia utente di amministrazione,
e il database effettivo.
E così vedrai una demo registrata dove passo
attraverso un mucchio di quelle cose
che ti ho appena mostrato.
In realtà lo sta facendo in
una forma demo, ma è anche per lo più in questa lezione.
E così il modello Django è la
versione di Django di un mappatore relazionale a oggetti.
Puoi scrivere codice Python dopo un po ',
specialmente se hai
un IDE che può mostrarti quali oggetti hanno e roba.
Si tende a, è molto più facile scrivere,
mentre SQL, devi conoscerlo e scriverlo.
Si ottiene la portabilità del database.
È possibile creare queste migrazioni per creare
lo schema iniziale nel database e quindi
evolvere lo schema man mano che l'applicazione si evolve.
Questa è una delle cose più preziose.
Se stai costruendo SQL direttamente,
passare dalla versione 1 del
tuo database alla versione 2 del tuo database è un
po 'frustrante e difficile.
A volte migrare ed evolvere un database è
più difficile che scrivere codice SQL in primo luogo,
e Django ti dà subito questa
interfaccia amministratore davvero interessante,
models.py e admin.py lo informano.
E più tardi, avremo
tutta questa generazione automatica di moduli.
E quindi quello che stiamo facendo qui è che sembra che abbiamo messo
come tre righe di codice in qualche file e
poi un sacco di magia accade,
ed è davvero così che funziona Django.
E l'idea è in questo modo,
tu come sviluppatore puoi concentrarti
sulle colonne del tuo database e sui moduli
che vuoi mettere
e dedicare sempre meno tempo a creare manualmente HTML che è
molto fragile, e SQL
meno fragile ma comunque fragile.
E quindi questa è l'idea e
quindi è un po 'difficile quando
inizi perché la quantità di codice che scrivi è
così piccola e ciò che realizza è così grande.
Ma dopo un po 'quando hai
capito tutti questi piccoli pezzi,
poi all'improvviso, sei tipo: «Ok, ora
voglio risolvere il
problema dell'utente finale», e puoi passare tutto il tuo tempo a
risolvere quel problema piuttosto che creare
database e cose del genere.
Allora, ci vediamo alla prossima lezione. Salute.
[ MUSIC]