Immagino che ormai la tua testa sia infestata da manguste o sia manguste?
Beh, non sono un maggiore inglese, quindi non ho idea di cosa sia il plurale.
In ogni caso, questo ci porta al tema di questa conferenza, popolazione mangusta.
Che cosa è esattamente la popolazione di Mangusta e
come è utile nella nostra applicazione espressa?
Parliamone dopo.
Come abbiamo capito, i database dei documenti, i database NoSQL,
non sono progettati con le relazioni in mente.
Tutto ciò di cui hai bisogno in un documento viene memorizzato completamente all'interno del documento.
Beh, questo è praticamente il modo in cui le cose funzionano con i database NoSQL come MongoDB.
Quindi non hai il supporto per le relazioni che potresti avere
più familiarità con dal mondo dei database relazionali.
Dove si dispone di record e quindi record possono fare riferimento ad altri record e così via.
E poi si uniscono per unire le informazioni dai record e così via.
Quindi questo tipo di supporto non esiste nei database NoSQL,
almeno in larga misura.
MongoDB ha fatto alcuni passi in quella direzione, anche con i database NoSQL.
Ma in generale, i database dei documenti si aspettano che tutti i documenti siano autonomi.
Quindi, il che significa che tutte le informazioni richieste sono all'interno dello stesso documento.
Ora, naturalmente, ci sono situazioni in cui hai altri documenti che
contenevano già le informazioni.
E potresti voler estrarre tali informazioni nel tuo documento esistente,
piuttosto che duplicarle.
Quindi questo è dove MongoDB o Mongoose,
consente di memorizzare riferimenti ad altri documenti all'interno di un documento corrente.
Il riferimento all'altro documento viene fatto utilizzando l'ObjectID di quell'
altro documento.
Ora, se questo è il caso, allora Mongusta consente di eseguire un modo di
prendere le informazioni dall'altro documento e quindi
racchiuderle all'interno del documento corretto utilizzando il supporto popolazione Mangusta.
Questo è ciò che discuteremo in modo un po 'più dettagliato.
Mongoose stessa, come ci rendiamo conto, essendo un modulo costruito
su MongoDB, non ha supporti espliciti per
i join, il modo in cui parliamo di join nel mondo SQL.
Per capire come questo riferimento dell'altro documento in un documento ci aiuta e
come è effettivamente strutturato, diamo un'occhiata a un esempio.
In questo esempio, vedremo il documento piatti che
abbiamo usato nel nostro esercizio.
Nei documenti piatti che memorizziamo sul lato server,
abbiamo notato che memorizziamo anche i commenti.
E all'interno dei commenti, memorizziamo anche un campo autore all'interno dei commenti.
E il campo autore contiene esplicitamente il nome della persona che
ha inviato quel commento specifico.
Ora, dal momento che abbiamo già un documento utente
all'interno del nostro database, come abbiamo visto in questo modulo.
Avevamo esteso il nostro server esperto per supportare gli utenti e quindi,
è possibile registrare un utente e che è possibile autenticare gli utenti e così via.
Quindi il documento utente può portare ulteriori informazioni sull'utente già.
E così quando un commento viene pubblicato dall'utente,
invece di memorizzare il nome dell'utente all'interno del commento stesso,
perché non avere un riferimento all'utente specifico che ha pubblicato il commento?
Questo è utile non solo in termini di essere in grado di
affrontare il fatto che questo commento è pubblicato dall'utente specifico.
In seguito, vedremo che se è necessario consentire agli utenti di modificare o
eliminare documenti, è possibile limitare il tipo
di operazione di un utente specifico solo ai commenti
che quell'utente specifico ha pubblicato in precedenza.
Anche se stiamo usando documenti secondari all'interno del nostro documento Mongo.
Se siamo in grado di fare riferimento a un altro documento nel sottodocumento utilizzando ObjectID,
allora Mongo ci aiuta a fare popolazione di queste
informazioni dall'altro documento nel documento corrente.
Quindi è qui che la popolazione di Mangusta viene in nostro soccorso.
Prendendo ulteriormente questa idea, permettetemi di mostrarvi un
esempio dettagliato dallo schema di commento che abbiamo definito in precedenza.
Quindi nel CommentSchema, abbiamo già il campo di valutazione e
il campo di commento che abbiamo già specificato lì.
Prima avevamo anche il campo autore.
Per il campo autore in precedenza, stavamo memorizzando l'autore come
una stringa e, Il valore predefinito anche per l'autore.
Ora, memorizzando l'autore come stringa di tipo, se ora trasformiamo
l'autore in un tipo di mongoose.schema.types.ObjectID.
Quindi il che significa che il campo autore ora conterrà un ObjectID,
che è un riferimento a un documento utente.
Come si assicura che questo faccia riferimento a un documento utente?
Quindi questo è dove questa proprietà aggiuntiva chiamata ref, che specifica che
lo schema del documento che si sta facendo riferimento qui è del tipo, l'utente,
lo schema e il modello che abbiamo già aggiunto in precedenza.
Quindi, in questo caso, lo schema di commento è ora esteso per memorizzare le informazioni dell'autore,
ma le informazioni dell'autore sono sotto forma di un ObjectID.
Che è un riferimento al documento utente che è già memorizzato nel nostro database.
Ora, in che modo questo ci aiuta?
Qui è dove, come ho detto, la popolazione mangusta viene in nostro aiuto.
Allora, come funziona la popolazione di Mangusta?
Con la popolazione mangusta, il modo in cui la popolazione mangusta funziona è che
sostituisce automaticamente i percorsi specificati all'interno di un documento corrente.
Che fa riferimento a un altro documento dalle informazioni di quell'altro documento.
Quindi, nello schema dei commenti, ad esempio, si dispone di un campo autore che
si riferisce all'ObjectID del documento utente già presente nel database.
Quindi, con la popolazione di Mangusta, quando chiedi a Mongusta di popolare questo documento piatto,
allora popolerà le informazioni sull'autore nel campo dei commenti
dal documento utente.
Quindi le informazioni sull'autore specifico a cui si fa riferimento saranno
recuperate e aggiunte nel documento piatto.
E il documento composto verra' costruito e poi rimandato a te.
Come facciamo a garantire che ciò accada?
Questo è dove ci aiuta quel riferimento incrociato con l'ObjectID, come abbiamo visto,.
Come fa la popolazione effettivamente accade in codice?
Dando uno sguardo a come vorremmo popolare, per
esempio, il documento piatti che abbiamo appena visto in precedenza.
In precedenza stavamo facendo piatti.Find per trovare tutti i piatti nel nostro database.
Ora, una volta trovato il documento Piatti, allora si può dire popolare.
E quindi fornire all'interno del popolare, come parametro,
il campo specifico che deve essere popolato.
Quindi qui stiamo specificando comments.author.
Ora l'aspettativa è che il campo comments.author sia
in realtà un OjectID che fa riferimento al documento utente.
Ed è così che abbiamo impostato il nostro schema di commento già.
Quindi questa chiamata popolare che eseguiamo qui andrà e
recupererà dal database ogni singolo record dell'autore o il record dell'utente.
E poi prendere quel documento utente e
popolarlo nel documento piatti per costruire il documento composto da qui.
E poi dopo, ovviamente,
c'è una successiva gestione dei dati che hai ottenuto.
E poi rispondere o restituire i dati al cliente può avvenire a questo punto.
Ma naturalmente, lasciatemi avvertire che questa operazione di popolazione
non è un compito facile da fare per il server.
Perché ogni singolo piatto, si dovrà esaminare ogni singolo commento.
Quindi per ogni commento, devi scoprire il loro ObjectID per
l'utente.
Poi vai a prendere quel documento utente e
poi lo popola all'interno del documento piatto.
E poi, questo deve essere ripetuto per
ogni singolo commento che è contenuto in quel documento Piatti.
In sostanza significa che ci vorrà molto più tempo per il lato server
per completare la richiesta e inviare le informazioni al lato client.
Quindi suggerirei che dovresti usare populate in modo molto giudizioso.
Dovresti usarlo solo in circostanze in cui hai davvero bisogno di queste informazioni.
Se, ad esempio, stai semplicemente costruendo il menu per il tuo ristorante.
Quando stai solo costruendo il menu per il tuo ristorante,
potresti non aver bisogno di popolare le informazioni sull'autore di ogni
commento nel documento del commento.
Perché quando stai solo rendendo il menu per il tuo ristorante,
non hai intenzione di mostrare i commenti per quel piatto specifico.
Ma invece, se l'utente sta esaminando un piatto specifico e
vuole vedere i commenti a quel punto,
potresti voler eseguire una richiesta lato server.
E poi recuperare le informazioni del commento con le altre informazioni dell'autore
popolate in e ottenere che per l'uso all'interno del nostro lato client.
Quindi, di nuovo, popolare è un modo meraviglioso di fare le cose quando richiesto,
ma usarlo in modo molto giudiziario, solo quando hai davvero bisogno di informazioni.
In modo che la flessibilità che popolano
ci fornisce è il fatto che non abbiamo bisogno di popolare quando non è necessario.
Ma possiamo popolare le informazioni quando abbiamo davvero bisogno di queste informazioni.
Con questa rapida comprensione della popolazione di
Mangusta, passiamo all'esercizio in cui modificheremo lo schema Piatti, lo schema
dei commenti all'interno dello schema Piatti.
E poi utilizzare Mongoose popolare per popolare le informazioni all'interno dei nostri piatti
quando stiamo restituendo le informazioni piatto sul lato server.
Inoltre, ciò implica anche che quando un commento viene aggiunto a un piatto specifico,
l'autore delle informazioni del commento deve essere catturato sul lato server.
Ora, si dà il caso che il modo in cui abbiamo sviluppato i nostri server,
abbiamo già queste informazioni che ci vengono fornite.
Quando autentichiamo l'utente, le informazioni dell'utente sono già caricate in ogni
richiesta che arriva dal lato client.
E così usano che le informazioni dell'utente sono a nostra disposizione.
Così, quando stiamo postando il commento sul lato server, ci sarà anche
catturare l'ID dell'utente e quindi memorizzarlo nel campo autore dello schema di commento.
Questo dovrebbe essere fatto automaticamente sul lato server.
Il client non dovrebbe essere autorizzato a compilare esplicitamente il campo autore.
Ma il lato server dovrebbe convalidare l'utente e solo per
gli utenti che hanno effettuato l'accesso, si consentirebbe loro di, prima di tutto, di pubblicare commenti.
E poi quando pubblicano commenti,
si riempirà automaticamente il campo autore per quel documento commento
sostituendo il campo autore con l'ObjectID dell'utente.
Ora, nell'esercizio, mi vedrai fare questo.
Quindi attenzione per quella cosa specifica nell'esercizio.
Con questo, completiamo questa lezione,
passiamo all'esercizio per esaminare l'uso della popolazione di Mangusta.
[ MUSIC]