1
00:00:04,652 --> 00:00:11,190
Je suppose que votre tête est infestée de mangoustes ou est-elle monoise ?

2
00:00:11,190 --> 00:00:16,500
Je ne suis pas major anglais, donc je n'ai aucune idée de ce qu'est le pluriel.

3
00:00:16,500 --> 00:00:22,770
En tout cas, cela nous amène au sujet de cette conférence, la population mongoose.

4
00:00:22,770 --> 00:00:25,120
Quelle est exactement la population mongoose et

5
00:00:25,120 --> 00:00:29,800
comment est-elle utile dans notre application express ?

6
00:00:29,800 --> 00:00:31,190
Parlons de ça ensuite.

7
00:00:33,100 --> 00:00:38,275
Comme nous l'avons réalisé, les bases de données de documents, les bases de données NoSQL,

8
00:00:38,275 --> 00:00:41,767
ne sont pas conçues avec des relations à l'esprit.

9
00:00:41,767 --> 00:00:46,570
Tout ce dont vous avez besoin dans un document est entièrement stocké dans le document.

10
00:00:46,570 --> 00:00:53,650
Eh bien, c'est à peu près la façon dont les choses fonctionnent avec les bases de données NoSQL comme MongoDB.

11
00:00:53,650 --> 00:00:58,490
Vous n'avez donc pas de support pour les relations que vous

12
00:00:58,490 --> 00:01:03,065
connaissez peut-être plus dans le monde de la base de données relationnelle.

13
00:01:03,065 --> 00:01:08,060
Où vous avez des enregistrements, puis des enregistrements peuvent référencer d'autres enregistrements et ainsi de suite.

14
00:01:08,060 --> 00:01:12,510
Et puis vous faites des jointures afin de joindre les informations des enregistrements et ainsi de suite.

15
00:01:12,510 --> 00:01:17,030
Donc, ce type de support n'existe pas dans les bases de données NoSQL,

16
00:01:17,030 --> 00:01:19,010
du moins dans une large mesure.

17
00:01:19,010 --> 00:01:25,120
MongoDB a fait quelques pas dans cette direction, même avec les bases de données NoSQL.

18
00:01:25,120 --> 00:01:31,030
Mais en général, les bases de données de documents s'attendent à ce que tous les documents soient autonomes.

19
00:01:31,030 --> 00:01:36,740
Donc, ce qui signifie que toutes les informations requises sont dans le même document.

20
00:01:36,740 --> 00:01:41,270
Maintenant, bien sûr, il y a des situations où vous avez d'autres documents qui

21
00:01:41,270 --> 00:01:43,657
contenaient déjà l'information.

22
00:01:43,657 --> 00:01:47,561
Vous voudrez peut-être extraire ces informations dans votre document existant,

23
00:01:47,561 --> 00:01:50,580
plutôt que de les dupliquer.

24
00:01:50,580 --> 00:01:57,390
C' est donc là que MongoDB ou Mongoose,

25
00:01:57,390 --> 00:02:04,290
vous permet de stocker des références à d'autres documents dans un document courant.

26
00:02:04,290 --> 00:02:08,953
La référence à l'autre document se fait à l'aide de l'ObjectID de cet

27
00:02:08,953 --> 00:02:10,125
autre document.

28
00:02:10,125 --> 00:02:14,773
Maintenant, si c'est le cas, alors Mongoose vous permet d'effectuer un moyen de

29
00:02:14,773 --> 00:02:19,588
prendre les informations de l'autre document et de les inclure

30
00:02:19,588 --> 00:02:25,010
dans le document correct en utilisant le soutien de la population mongoose.

31
00:02:25,010 --> 00:02:28,230
C' est ce que nous allons discuter un peu plus en détail.

32
00:02:28,230 --> 00:02:33,227
Mongoose lui-même, comme nous le réalisons, étant un module construit

33
00:02:33,227 --> 00:02:38,336
sur MongoDB, n'a pas de support explicite pour les

34
00:02:38,336 --> 00:02:43,135
jointures, la façon dont nous parlons de jointures dans le monde SQL.

35
00:02:43,135 --> 00:02:48,471
Pour comprendre comment ce référencement de l'autre document dans un document nous aide et

36
00:02:48,471 --> 00:02:53,210
comment il est réellement structuré, prenons un exemple.

37
00:02:53,210 --> 00:02:58,420
Dans cet exemple, nous examinerons le document de plats que nous

38
00:02:58,420 --> 00:03:01,210
avons utilisé dans notre exercice.

39
00:03:01,210 --> 00:03:04,540
Dans les documents plats que nous stockons du côté serveur,

40
00:03:04,540 --> 00:03:07,590
nous avons remarqué que nous stockons également les commentaires.

41
00:03:07,590 --> 00:03:12,366
Et dans les commentaires, nous stockons également un champ auteur dans les commentaires.

42
00:03:12,366 --> 00:03:16,750
Et le champ auteur contient explicitement le nom de la personne qui

43
00:03:16,750 --> 00:03:19,890
a soumis ce commentaire spécifique.

44
00:03:19,890 --> 00:03:24,961
Maintenant, puisque nous avons déjà un document utilisateur

45
00:03:24,961 --> 00:03:30,453
dans notre base de données, comme nous l'avons vu dans ce module.

46
00:03:30,453 --> 00:03:35,151
Nous avions étendu notre serveur expert pour soutenir les utilisateurs et ainsi,

47
00:03:35,151 --> 00:03:40,440
vous pouvez enregistrer un utilisateur et que vous pouvez authentifier les utilisateurs et ainsi de suite.

48
00:03:40,440 --> 00:03:45,790
Ainsi, le document utilisateur peut contenir des informations supplémentaires sur l'utilisateur déjà.

49
00:03:46,810 --> 00:03:49,302
Et donc, quand un commentaire est posté par l'utilisateur,

50
00:03:49,302 --> 00:03:53,043
au lieu de stocker le nom de l'utilisateur dans le commentaire lui-même,

51
00:03:53,043 --> 00:03:57,360
pourquoi ne pas avoir une référence à l'utilisateur spécifique qui a posté le commentaire ?

52
00:03:58,360 --> 00:04:02,570
Ceci est utile non seulement en termes de pouvoir

53
00:04:02,570 --> 00:04:07,680
traiter le fait que ce commentaire est publié par l'utilisateur spécifique.

54
00:04:07,680 --> 00:04:13,934
Plus tard, nous verrons que si vous avez besoin d'autoriser les utilisateurs à modifier ou

55
00:04:13,934 --> 00:04:19,126
supprimer des documents, vous voudrez peut-être limiter le type

56
00:04:19,126 --> 00:04:24,436
d'opération d'un utilisateur spécifique aux commentaires

57
00:04:24,436 --> 00:04:28,937
que cet utilisateur spécifique a postés plus tôt.

58
00:04:28,937 --> 00:04:36,649
Même si nous utilisons des sous-documents dans notre document Mongo.

59
00:04:36,649 --> 00:04:42,292
Si nous pouvons référencer un autre document dans le sous-document en utilisant ObjectID,

60
00:04:42,292 --> 00:04:45,415
alors Mongo nous aide à faire la population de cette

61
00:04:45,415 --> 00:04:50,450
information de l'autre document dans le document actif.

62
00:04:50,450 --> 00:04:54,370
C' est là que la population mongoose vient à notre secours.

63
00:04:54,370 --> 00:04:57,770
Pour aller plus loin cette idée, permettez-moi de vous montrer un

64
00:04:57,770 --> 00:05:02,600
exemple détaillé du schéma de commentaire que nous avons défini précédemment.

65
00:05:02,600 --> 00:05:06,850
Donc, dans le CommentSchema, nous avons déjà le champ de notation et

66
00:05:06,850 --> 00:05:10,080
le champ de commentaire que nous avons déjà spécifié là-bas.

67
00:05:10,080 --> 00:05:13,320
Nous avions également l'habitude d'avoir le champ auteur plus tôt.

68
00:05:13,320 --> 00:05:18,133
Pour le champ auteur précédemment, nous stockions l'auteur sous

69
00:05:18,133 --> 00:05:23,270
forme de chaîne et, La valeur par défaut aussi pour l'auteur.

70
00:05:23,270 --> 00:05:28,285
Maintenant, en stockant l'auteur comme une chaîne de type, si nous transformons maintenant

71
00:05:28,285 --> 00:05:34,200
l'auteur en un type de Mongoose.schema.types.Objectid.

72
00:05:34,200 --> 00:05:39,350
Donc, ce qui signifie que le champ auteur contiendra maintenant un ObjectID,

73
00:05:39,350 --> 00:05:42,870
qui est une référence à un document utilisateur.

74
00:05:42,870 --> 00:05:46,090
Comment vous assurer que cela fait référence à un document utilisateur ?

75
00:05:46,090 --> 00:05:51,500
C' est donc là que cette propriété supplémentaire appelée ref, qui spécifie que

76
00:05:51,500 --> 00:05:56,160
le schéma du document que vous faites référence ici est du type, l'utilisateur, le

77
00:05:56,160 --> 00:05:59,590
schéma et le modèle que nous avons déjà ajouté précédemment.

78
00:05:59,590 --> 00:06:05,144
Donc, dans ce cas, le schéma de commentaire est maintenant étendu pour stocker les informations de l'auteur,

79
00:06:05,144 --> 00:06:08,706
mais les informations de l'auteur sont sous la forme d'un ObjectID.

80
00:06:08,706 --> 00:06:15,480
Qui est une référence au document utilisateur qui est déjà stocké dans notre base de données.

81
00:06:15,480 --> 00:06:17,750
Comment ça nous aide ?

82
00:06:17,750 --> 00:06:22,667
C' est là que, comme je l'ai dit, la population mongoose vient à notre aide.

83
00:06:22,667 --> 00:06:25,120
Alors, comment fonctionne la population mongoose ?

84
00:06:25,120 --> 00:06:30,150
Avec la population mongoose, la façon dont la population mongoose fonctionne est qu'

85
00:06:30,150 --> 00:06:35,363
elle remplace automatiquement les chemins spécifiés dans un document courant.

86
00:06:35,363 --> 00:06:40,850
Qui fait référence à un autre document par l'information de cet autre document.

87
00:06:40,850 --> 00:06:46,282
Ainsi, dans le schéma de commentaire, par exemple, vous avez un champ auteur qui

88
00:06:46,282 --> 00:06:53,070
fait référence à l'ObjectID du document utilisateur qui se trouve déjà dans votre base de données.

89
00:06:53,070 --> 00:06:58,963
Donc, avec la population mongoose, lorsque vous demandez à Mongoose de remplir ce document plat,

90
00:06:58,963 --> 00:07:03,820
alors il remplira les informations sur l'auteur dans le champ commentaire

91
00:07:03,820 --> 00:07:05,240
du document utilisateur.

92
00:07:05,240 --> 00:07:09,447
Ainsi, les informations sur l'auteur spécifique qui y est référencé seront

93
00:07:09,447 --> 00:07:12,130
récupérées et ajoutées dans votre document plat.

94
00:07:12,130 --> 00:07:16,820
Et le document composé sera construit et ensuite renvoyé à vous.

95
00:07:16,820 --> 00:07:19,370
Comment faire en sorte que cela se produise ?

96
00:07:19,370 --> 00:07:25,020
C' est là que cette référence croisée avec l'ObjectID, comme nous l'avons vu, nous aide.

97
00:07:25,020 --> 00:07:30,890
Comment la population se produit-elle réellement dans le code ? En

98
00:07:30,890 --> 00:07:33,350
regardant comment nous pourrions remplir,

99
00:07:33,350 --> 00:07:38,090
par exemple, le document des plats que nous venons de voir plus tôt.

100
00:07:38,090 --> 00:07:43,650
Plus tôt, nous faisions des plats.Trouver pour trouver tous les plats dans notre base de données.

101
00:07:43,650 --> 00:07:48,645
Maintenant, une fois que vous avez trouvé le document Plats, vous pouvez dire « remplir ».

102
00:07:48,645 --> 00:07:52,647
Ensuite, fournissez dans le remplissage, en tant que paramètre,

103
00:07:52,647 --> 00:07:56,130
le champ spécifique qui doit être rempli.

104
00:07:56,130 --> 00:07:59,380
Donc, ici, nous spécifions comments.author.

105
00:07:59,380 --> 00:08:02,270
Maintenant, l'attente est que le champ comments.author est

106
00:08:02,270 --> 00:08:06,550
en fait un objet ObjectiID qui fait référence au document utilisateur.

107
00:08:06,550 --> 00:08:10,502
Et c'est ainsi que nous avons déjà mis en place notre schéma de commentaires.

108
00:08:10,502 --> 00:08:16,418
Donc, cet appel de remplissage que nous effectuons ici va aller

109
00:08:16,418 --> 00:08:24,937
chercher à partir de la base de données chaque enregistrement de l'auteur individuel ou de l'enregistrement de l'utilisateur.

110
00:08:24,937 --> 00:08:27,457
Et puis prenez ce document utilisateur et le

111
00:08:27,457 --> 00:08:33,505
remplit dans le document plats pour construire le document composé à partir d'ici.

112
00:08:33,505 --> 00:08:35,525
Et puis après cela, bien sûr,

113
00:08:35,525 --> 00:08:39,579
il y a un traitement ultérieur des données que vous avez obtenues.

114
00:08:39,579 --> 00:08:44,640
Et puis la réponse ou le retour des données au client peut avoir lieu à ce stade.

115
00:08:44,640 --> 00:08:49,110
Mais bien sûr, laissez-moi vous avertir que cette opération de population

116
00:08:49,110 --> 00:08:52,020
n'est pas une tâche facile pour le serveur.

117
00:08:52,020 --> 00:08:56,825
Parce que chaque plat, vous devrez examiner chaque commentaire.

118
00:08:56,825 --> 00:09:01,385
Ensuite, pour chaque commentaire, vous devez trouver leur ObjectID pour

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

120
00:09:02,034 --> 00:09:04,580
Ensuite, vous allez chercher ce document utilisateur

121
00:09:04,580 --> 00:09:07,203
, puis le remplir dans le document plat.

122
00:09:07,203 --> 00:09:09,329
Et puis, cela doit être répété pour

123
00:09:09,329 --> 00:09:13,113
chaque commentaire contenu dans ce document Plats.

124
00:09:13,113 --> 00:09:18,437
Cela signifie essentiellement que le côté serveur prendra beaucoup plus de temps

125
00:09:18,437 --> 00:09:23,720
pour terminer la demande et renvoyer les informations vers le client.

126
00:09:23,720 --> 00:09:31,020
Donc, je suggère que vous devriez utiliser populate très judicieusement.

127
00:09:31,020 --> 00:09:35,410
Vous ne devriez l'utiliser que dans les circonstances où vous avez vraiment besoin de cette information.

128
00:09:36,590 --> 00:09:42,529
Si, par exemple, vous construisez simplement le menu de votre restaurant.

129
00:09:42,529 --> 00:09:46,522
Lorsque vous construisez simplement le menu de votre restaurant, il

130
00:09:46,522 --> 00:09:51,267
se peut que vous n'ayez pas vraiment besoin de renseigner les informations sur l'auteur de chaque

131
00:09:51,267 --> 00:09:54,010
commentaire dans le document de commentaire.

132
00:09:54,010 --> 00:09:57,270
Parce que lorsque vous ne faites que rendre le menu de votre restaurant,

133
00:09:57,270 --> 00:10:01,730
vous n'allez pas montrer les commentaires pour ce plat spécifique.

134
00:10:01,730 --> 00:10:06,457
Mais au lieu de cela, si l'utilisateur examine un plat spécifique et

135
00:10:06,457 --> 00:10:09,804
veut voir les commentaires à ce stade,

136
00:10:09,804 --> 00:10:13,660
vous pouvez exécuter une requête côté serveur.

137
00:10:13,660 --> 00:10:19,383
Et puis récupérez les informations de commentaire avec les autres informations d'auteur

138
00:10:19,383 --> 00:10:24,540
renseignées et obtenez-vous cela pour une utilisation dans notre côté client.

139
00:10:24,540 --> 00:10:30,240
Encore une fois, peupler est une merveilleuse façon de faire les choses quand

140
00:10:30,240 --> 00:10:35,610
il est nécessaire, mais l'utiliser de façon très judicieuse, seulement lorsque vous avez vraiment besoin de l'information.

141
00:10:35,610 --> 00:10:38,370
Donc, cette flexibilité qui

142
00:10:38,370 --> 00:10:42,540
nous fournit est le fait que nous n'avons pas besoin de remplir quand nous n'avons pas à le faire.

143
00:10:42,540 --> 00:10:46,990
Mais nous pouvons remplir l'information quand nous en avons vraiment besoin.

144
00:10:48,030 --> 00:10:51,450
Avec cette compréhension rapide de la population mongoose,

145
00:10:51,450 --> 00:10:57,280
passons à l'exercice où nous allons modifier le schéma Discs,

146
00:10:57,280 --> 00:10:59,840
le schéma des commentaires dans le schéma Discs.

147
00:10:59,840 --> 00:11:04,730
Et puis utilisez Mongoose populate pour remplir les informations dans nos plats

148
00:11:04,730 --> 00:11:09,255
lorsque nous retournons les informations sur le plat côté serveur.

149
00:11:09,255 --> 00:11:15,745
En outre, cela implique également que lorsqu'un commentaire est ajouté à un plat spécifique,

150
00:11:16,775 --> 00:11:22,210
l'auteur des informations du commentaire doit être capturé côté serveur.

151
00:11:22,210 --> 00:11:26,079
Maintenant, il se trouve que la façon dont nous avons développé nos serveurs,

152
00:11:26,079 --> 00:11:29,740
nous avons déjà cette information qui nous est fournie.

153
00:11:29,740 --> 00:11:34,870
Lorsque nous authentifions l'utilisateur, les informations de l'utilisateur sont déjà chargées dans chaque

154
00:11:34,870 --> 00:11:37,580
requête qui vient du côté client.

155
00:11:37,580 --> 00:11:41,200
Et donc ils utilisent les informations de l'utilisateur qui nous sont disponibles.

156
00:11:41,200 --> 00:11:46,170
Donc, lorsque nous postons le commentaire côté serveur, nous allons également

157
00:11:46,170 --> 00:11:52,370
capturer l'ID de l'utilisateur, puis le stocker dans le champ auteur du schéma de commentaire.

158
00:11:52,370 --> 00:11:55,430
Cela devrait être fait automatiquement côté serveur.

159
00:11:55,430 --> 00:12:00,740
Le client ne doit pas être autorisé à remplir explicitement le champ auteur.

160
00:12:00,740 --> 00:12:04,348
Mais le côté serveur devrait valider l'utilisateur et seulement pour

161
00:12:04,348 --> 00:12:10,020
les utilisateurs qui sont connectés, vous leur permettrez, tout d'abord, de poster des commentaires.

162
00:12:10,020 --> 00:12:12,688
Puis, lorsqu'ils publient des commentaires,

163
00:12:12,688 --> 00:12:18,392
vous remplissez automatiquement le champ auteur de ce document de commentaire

164
00:12:18,392 --> 00:12:23,740
en remplaçant le champ auteur par l'ObjectID de l'utilisateur.

165
00:12:23,740 --> 00:12:25,920
Maintenant, dans l'exercice, vous me verrez faire ça.

166
00:12:25,920 --> 00:12:30,780
Alors attention à cette chose spécifique dans l'exercice.

167
00:12:30,780 --> 00:12:33,245
Avec cela, nous terminons cette conférence,

168
00:12:33,245 --> 00:12:38,109
passons à l'exercice pour examiner l'utilisation de la population mongoose.

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