1
00:00:04,652 --> 00:00:11,190
Immagino che ormai la tua testa sia infestata da manguste o sia manguste?

2
00:00:11,190 --> 00:00:16,500
Beh, non sono un maggiore inglese, quindi non ho idea di cosa sia il plurale.

3
00:00:16,500 --> 00:00:22,770
In ogni caso, questo ci porta al tema di questa conferenza, popolazione mangusta.

4
00:00:22,770 --> 00:00:25,120
Che cosa è esattamente la popolazione di Mangusta e

5
00:00:25,120 --> 00:00:29,800
come è utile nella nostra applicazione espressa?

6
00:00:29,800 --> 00:00:31,190
Parliamone dopo.

7
00:00:33,100 --> 00:00:38,275
Come abbiamo capito, i database dei documenti, i database NoSQL,

8
00:00:38,275 --> 00:00:41,767
non sono progettati con le relazioni in mente.

9
00:00:41,767 --> 00:00:46,570
Tutto ciò di cui hai bisogno in un documento viene memorizzato completamente all'interno del documento.

10
00:00:46,570 --> 00:00:53,650
Beh, questo è praticamente il modo in cui le cose funzionano con i database NoSQL come MongoDB.

11
00:00:53,650 --> 00:00:58,490
Quindi non hai il supporto per le relazioni che potresti avere

12
00:00:58,490 --> 00:01:03,065
più familiarità con dal mondo dei database relazionali.

13
00:01:03,065 --> 00:01:08,060
Dove si dispone di record e quindi record possono fare riferimento ad altri record e così via.

14
00:01:08,060 --> 00:01:12,510
E poi si uniscono per unire le informazioni dai record e così via.

15
00:01:12,510 --> 00:01:17,030
Quindi questo tipo di supporto non esiste nei database NoSQL,

16
00:01:17,030 --> 00:01:19,010
almeno in larga misura.

17
00:01:19,010 --> 00:01:25,120
MongoDB ha fatto alcuni passi in quella direzione, anche con i database NoSQL.

18
00:01:25,120 --> 00:01:31,030
Ma in generale, i database dei documenti si aspettano che tutti i documenti siano autonomi.

19
00:01:31,030 --> 00:01:36,740
Quindi, il che significa che tutte le informazioni richieste sono all'interno dello stesso documento.

20
00:01:36,740 --> 00:01:41,270
Ora, naturalmente, ci sono situazioni in cui hai altri documenti che

21
00:01:41,270 --> 00:01:43,657
contenevano già le informazioni.

22
00:01:43,657 --> 00:01:47,561
E potresti voler estrarre tali informazioni nel tuo documento esistente,

23
00:01:47,561 --> 00:01:50,580
piuttosto che duplicarle.

24
00:01:50,580 --> 00:01:57,390
Quindi questo è dove MongoDB o Mongoose,

25
00:01:57,390 --> 00:02:04,290
consente di memorizzare riferimenti ad altri documenti all'interno di un documento corrente.

26
00:02:04,290 --> 00:02:08,953
Il riferimento all'altro documento viene fatto utilizzando l'ObjectID di quell'

27
00:02:08,953 --> 00:02:10,125
altro documento.

28
00:02:10,125 --> 00:02:14,773
Ora, se questo è il caso, allora Mongusta consente di eseguire un modo di

29
00:02:14,773 --> 00:02:19,588
prendere le informazioni dall'altro documento e quindi

30
00:02:19,588 --> 00:02:25,010
racchiuderle all'interno del documento corretto utilizzando il supporto popolazione Mangusta.

31
00:02:25,010 --> 00:02:28,230
Questo è ciò che discuteremo in modo un po 'più dettagliato.

32
00:02:28,230 --> 00:02:33,227
Mongoose stessa, come ci rendiamo conto, essendo un modulo costruito

33
00:02:33,227 --> 00:02:38,336
su MongoDB, non ha supporti espliciti per

34
00:02:38,336 --> 00:02:43,135
i join, il modo in cui parliamo di join nel mondo SQL.

35
00:02:43,135 --> 00:02:48,471
Per capire come questo riferimento dell'altro documento in un documento ci aiuta e

36
00:02:48,471 --> 00:02:53,210
come è effettivamente strutturato, diamo un'occhiata a un esempio.

37
00:02:53,210 --> 00:02:58,420
In questo esempio, vedremo il documento piatti che

38
00:02:58,420 --> 00:03:01,210
abbiamo usato nel nostro esercizio.

39
00:03:01,210 --> 00:03:04,540
Nei documenti piatti che memorizziamo sul lato server,

40
00:03:04,540 --> 00:03:07,590
abbiamo notato che memorizziamo anche i commenti.

41
00:03:07,590 --> 00:03:12,366
E all'interno dei commenti, memorizziamo anche un campo autore all'interno dei commenti.

42
00:03:12,366 --> 00:03:16,750
E il campo autore contiene esplicitamente il nome della persona che

43
00:03:16,750 --> 00:03:19,890
ha inviato quel commento specifico.

44
00:03:19,890 --> 00:03:24,961
Ora, dal momento che abbiamo già un documento utente

45
00:03:24,961 --> 00:03:30,453
all'interno del nostro database, come abbiamo visto in questo modulo.

46
00:03:30,453 --> 00:03:35,151
Avevamo esteso il nostro server esperto per supportare gli utenti e quindi,

47
00:03:35,151 --> 00:03:40,440
è possibile registrare un utente e che è possibile autenticare gli utenti e così via.

48
00:03:40,440 --> 00:03:45,790
Quindi il documento utente può portare ulteriori informazioni sull'utente già.

49
00:03:46,810 --> 00:03:49,302
E così quando un commento viene pubblicato dall'utente,

50
00:03:49,302 --> 00:03:53,043
invece di memorizzare il nome dell'utente all'interno del commento stesso,

51
00:03:53,043 --> 00:03:57,360
perché non avere un riferimento all'utente specifico che ha pubblicato il commento?

52
00:03:58,360 --> 00:04:02,570
Questo è utile non solo in termini di essere in grado di

53
00:04:02,570 --> 00:04:07,680
affrontare il fatto che questo commento è pubblicato dall'utente specifico.

54
00:04:07,680 --> 00:04:13,934
In seguito, vedremo che se è necessario consentire agli utenti di modificare o

55
00:04:13,934 --> 00:04:19,126
eliminare documenti, è possibile limitare il tipo

56
00:04:19,126 --> 00:04:24,436
di operazione di un utente specifico solo ai commenti

57
00:04:24,436 --> 00:04:28,937
che quell'utente specifico ha pubblicato in precedenza.

58
00:04:28,937 --> 00:04:36,649
Anche se stiamo usando documenti secondari all'interno del nostro documento Mongo.

59
00:04:36,649 --> 00:04:42,292
Se siamo in grado di fare riferimento a un altro documento nel sottodocumento utilizzando ObjectID,

60
00:04:42,292 --> 00:04:45,415
allora Mongo ci aiuta a fare popolazione di queste

61
00:04:45,415 --> 00:04:50,450
informazioni dall'altro documento nel documento corrente.

62
00:04:50,450 --> 00:04:54,370
Quindi è qui che la popolazione di Mangusta viene in nostro soccorso.

63
00:04:54,370 --> 00:04:57,770
Prendendo ulteriormente questa idea, permettetemi di mostrarvi un

64
00:04:57,770 --> 00:05:02,600
esempio dettagliato dallo schema di commento che abbiamo definito in precedenza.

65
00:05:02,600 --> 00:05:06,850
Quindi nel CommentSchema, abbiamo già il campo di valutazione e

66
00:05:06,850 --> 00:05:10,080
il campo di commento che abbiamo già specificato lì.

67
00:05:10,080 --> 00:05:13,320
Prima avevamo anche il campo autore.

68
00:05:13,320 --> 00:05:18,133
Per il campo autore in precedenza, stavamo memorizzando l'autore come

69
00:05:18,133 --> 00:05:23,270
una stringa e, Il valore predefinito anche per l'autore.

70
00:05:23,270 --> 00:05:28,285
Ora, memorizzando l'autore come stringa di tipo, se ora trasformiamo

71
00:05:28,285 --> 00:05:34,200
l'autore in un tipo di mongoose.schema.types.ObjectID.

72
00:05:34,200 --> 00:05:39,350
Quindi il che significa che il campo autore ora conterrà un ObjectID,

73
00:05:39,350 --> 00:05:42,870
che è un riferimento a un documento utente.

74
00:05:42,870 --> 00:05:46,090
Come si assicura che questo faccia riferimento a un documento utente?

75
00:05:46,090 --> 00:05:51,500
Quindi questo è dove questa proprietà aggiuntiva chiamata ref, che specifica che

76
00:05:51,500 --> 00:05:56,160
lo schema del documento che si sta facendo riferimento qui è del tipo, l'utente,

77
00:05:56,160 --> 00:05:59,590
lo schema e il modello che abbiamo già aggiunto in precedenza.

78
00:05:59,590 --> 00:06:05,144
Quindi, in questo caso, lo schema di commento è ora esteso per memorizzare le informazioni dell'autore,

79
00:06:05,144 --> 00:06:08,706
ma le informazioni dell'autore sono sotto forma di un ObjectID.

80
00:06:08,706 --> 00:06:15,480
Che è un riferimento al documento utente che è già memorizzato nel nostro database.

81
00:06:15,480 --> 00:06:17,750
Ora, in che modo questo ci aiuta?

82
00:06:17,750 --> 00:06:22,667
Qui è dove, come ho detto, la popolazione mangusta viene in nostro aiuto.

83
00:06:22,667 --> 00:06:25,120
Allora, come funziona la popolazione di Mangusta?

84
00:06:25,120 --> 00:06:30,150
Con la popolazione mangusta, il modo in cui la popolazione mangusta funziona è che

85
00:06:30,150 --> 00:06:35,363
sostituisce automaticamente i percorsi specificati all'interno di un documento corrente.

86
00:06:35,363 --> 00:06:40,850
Che fa riferimento a un altro documento dalle informazioni di quell'altro documento.

87
00:06:40,850 --> 00:06:46,282
Quindi, nello schema dei commenti, ad esempio, si dispone di un campo autore che

88
00:06:46,282 --> 00:06:53,070
si riferisce all'ObjectID del documento utente già presente nel database.

89
00:06:53,070 --> 00:06:58,963
Quindi, con la popolazione di Mangusta, quando chiedi a Mongusta di popolare questo documento piatto,

90
00:06:58,963 --> 00:07:03,820
allora popolerà le informazioni sull'autore nel campo dei commenti

91
00:07:03,820 --> 00:07:05,240
dal documento utente.

92
00:07:05,240 --> 00:07:09,447
Quindi le informazioni sull'autore specifico a cui si fa riferimento saranno

93
00:07:09,447 --> 00:07:12,130
recuperate e aggiunte nel documento piatto.

94
00:07:12,130 --> 00:07:16,820
E il documento composto verra' costruito e poi rimandato a te.

95
00:07:16,820 --> 00:07:19,370
Come facciamo a garantire che ciò accada?

96
00:07:19,370 --> 00:07:25,020
Questo è dove ci aiuta quel riferimento incrociato con l'ObjectID, come abbiamo visto,.

97
00:07:25,020 --> 00:07:30,890
Come fa la popolazione effettivamente accade in codice?

98
00:07:30,890 --> 00:07:33,350
Dando uno sguardo a come vorremmo popolare, per

99
00:07:33,350 --> 00:07:38,090
esempio, il documento piatti che abbiamo appena visto in precedenza.

100
00:07:38,090 --> 00:07:43,650
In precedenza stavamo facendo piatti.Find per trovare tutti i piatti nel nostro database.

101
00:07:43,650 --> 00:07:48,645
Ora, una volta trovato il documento Piatti, allora si può dire popolare.

102
00:07:48,645 --> 00:07:52,647
E quindi fornire all'interno del popolare, come parametro,

103
00:07:52,647 --> 00:07:56,130
il campo specifico che deve essere popolato.

104
00:07:56,130 --> 00:07:59,380
Quindi qui stiamo specificando comments.author.

105
00:07:59,380 --> 00:08:02,270
Ora l'aspettativa è che il campo comments.author sia

106
00:08:02,270 --> 00:08:06,550
in realtà un OjectID che fa riferimento al documento utente.

107
00:08:06,550 --> 00:08:10,502
Ed è così che abbiamo impostato il nostro schema di commento già.

108
00:08:10,502 --> 00:08:16,418
Quindi questa chiamata popolare che eseguiamo qui andrà e

109
00:08:16,418 --> 00:08:24,937
recupererà dal database ogni singolo record dell'autore o il record dell'utente.

110
00:08:24,937 --> 00:08:27,457
E poi prendere quel documento utente e

111
00:08:27,457 --> 00:08:33,505
popolarlo nel documento piatti per costruire il documento composto da qui.

112
00:08:33,505 --> 00:08:35,525
E poi dopo, ovviamente,

113
00:08:35,525 --> 00:08:39,579
c'è una successiva gestione dei dati che hai ottenuto.

114
00:08:39,579 --> 00:08:44,640
E poi rispondere o restituire i dati al cliente può avvenire a questo punto.

115
00:08:44,640 --> 00:08:49,110
Ma naturalmente, lasciatemi avvertire che questa operazione di popolazione

116
00:08:49,110 --> 00:08:52,020
non è un compito facile da fare per il server.

117
00:08:52,020 --> 00:08:56,825
Perché ogni singolo piatto, si dovrà esaminare ogni singolo commento.

118
00:08:56,825 --> 00:09:01,385
Quindi per ogni commento, devi scoprire il loro ObjectID per

119
00:09:01,385 --> 00:09:02,034
l'utente.

120
00:09:02,034 --> 00:09:04,580
Poi vai a prendere quel documento utente e

121
00:09:04,580 --> 00:09:07,203
poi lo popola all'interno del documento piatto.

122
00:09:07,203 --> 00:09:09,329
E poi, questo deve essere ripetuto per

123
00:09:09,329 --> 00:09:13,113
ogni singolo commento che è contenuto in quel documento Piatti.

124
00:09:13,113 --> 00:09:18,437
In sostanza significa che ci vorrà molto più tempo per il lato server

125
00:09:18,437 --> 00:09:23,720
per completare la richiesta e inviare le informazioni al lato client.

126
00:09:23,720 --> 00:09:31,020
Quindi suggerirei che dovresti usare populate in modo molto giudizioso.

127
00:09:31,020 --> 00:09:35,410
Dovresti usarlo solo in circostanze in cui hai davvero bisogno di queste informazioni.

128
00:09:36,590 --> 00:09:42,529
Se, ad esempio, stai semplicemente costruendo il menu per il tuo ristorante.

129
00:09:42,529 --> 00:09:46,522
Quando stai solo costruendo il menu per il tuo ristorante,

130
00:09:46,522 --> 00:09:51,267
potresti non aver bisogno di popolare le informazioni sull'autore di ogni

131
00:09:51,267 --> 00:09:54,010
commento nel documento del commento.

132
00:09:54,010 --> 00:09:57,270
Perché quando stai solo rendendo il menu per il tuo ristorante,

133
00:09:57,270 --> 00:10:01,730
non hai intenzione di mostrare i commenti per quel piatto specifico.

134
00:10:01,730 --> 00:10:06,457
Ma invece, se l'utente sta esaminando un piatto specifico e

135
00:10:06,457 --> 00:10:09,804
vuole vedere i commenti a quel punto,

136
00:10:09,804 --> 00:10:13,660
potresti voler eseguire una richiesta lato server.

137
00:10:13,660 --> 00:10:19,383
E poi recuperare le informazioni del commento con le altre informazioni dell'autore

138
00:10:19,383 --> 00:10:24,540
popolate in e ottenere che per l'uso all'interno del nostro lato client.

139
00:10:24,540 --> 00:10:30,240
Quindi, di nuovo, popolare è un modo meraviglioso di fare le cose quando richiesto,

140
00:10:30,240 --> 00:10:35,610
ma usarlo in modo molto giudiziario, solo quando hai davvero bisogno di informazioni.

141
00:10:35,610 --> 00:10:38,370
In modo che la flessibilità che popolano

142
00:10:38,370 --> 00:10:42,540
ci fornisce è il fatto che non abbiamo bisogno di popolare quando non è necessario.

143
00:10:42,540 --> 00:10:46,990
Ma possiamo popolare le informazioni quando abbiamo davvero bisogno di queste informazioni.

144
00:10:48,030 --> 00:10:51,450
Con questa rapida comprensione della popolazione di

145
00:10:51,450 --> 00:10:57,280
Mangusta, passiamo all'esercizio in cui modificheremo lo schema Piatti, lo schema

146
00:10:57,280 --> 00:10:59,840
dei commenti all'interno dello schema Piatti.

147
00:10:59,840 --> 00:11:04,730
E poi utilizzare Mongoose popolare per popolare le informazioni all'interno dei nostri piatti

148
00:11:04,730 --> 00:11:09,255
quando stiamo restituendo le informazioni piatto sul lato server.

149
00:11:09,255 --> 00:11:15,745
Inoltre, ciò implica anche che quando un commento viene aggiunto a un piatto specifico,

150
00:11:16,775 --> 00:11:22,210
l'autore delle informazioni del commento deve essere catturato sul lato server.

151
00:11:22,210 --> 00:11:26,079
Ora, si dà il caso che il modo in cui abbiamo sviluppato i nostri server,

152
00:11:26,079 --> 00:11:29,740
abbiamo già queste informazioni che ci vengono fornite.

153
00:11:29,740 --> 00:11:34,870
Quando autentichiamo l'utente, le informazioni dell'utente sono già caricate in ogni

154
00:11:34,870 --> 00:11:37,580
richiesta che arriva dal lato client.

155
00:11:37,580 --> 00:11:41,200
E così usano che le informazioni dell'utente sono a nostra disposizione.

156
00:11:41,200 --> 00:11:46,170
Così, quando stiamo postando il commento sul lato server, ci sarà anche

157
00:11:46,170 --> 00:11:52,370
catturare l'ID dell'utente e quindi memorizzarlo nel campo autore dello schema di commento.

158
00:11:52,370 --> 00:11:55,430
Questo dovrebbe essere fatto automaticamente sul lato server.

159
00:11:55,430 --> 00:12:00,740
Il client non dovrebbe essere autorizzato a compilare esplicitamente il campo autore.

160
00:12:00,740 --> 00:12:04,348
Ma il lato server dovrebbe convalidare l'utente e solo per

161
00:12:04,348 --> 00:12:10,020
gli utenti che hanno effettuato l'accesso, si consentirebbe loro di, prima di tutto, di pubblicare commenti.

162
00:12:10,020 --> 00:12:12,688
E poi quando pubblicano commenti,

163
00:12:12,688 --> 00:12:18,392
si riempirà automaticamente il campo autore per quel documento commento

164
00:12:18,392 --> 00:12:23,740
sostituendo il campo autore con l'ObjectID dell'utente.

165
00:12:23,740 --> 00:12:25,920
Ora, nell'esercizio, mi vedrai fare questo.

166
00:12:25,920 --> 00:12:30,780
Quindi attenzione per quella cosa specifica nell'esercizio.

167
00:12:30,780 --> 00:12:33,245
Con questo, completiamo questa lezione,

168
00:12:33,245 --> 00:12:38,109
passiamo all'esercizio per esaminare l'uso della popolazione di Mangusta.

169
00:12:38,109 --> 00:12:44,079
[ MUSIC]