1
00:00:00,000 --> 00:00:04,652
[MÚSICA]

2
00:00:04,652 --> 00:00:11,190
Acho que agora, sua cabeça está infestada de mangustos ou é mongansos?

3
00:00:11,190 --> 00:00:16,500
Bem, eu não sou estudante de inglês, então eu não tenho idéia do que é o plural.

4
00:00:16,500 --> 00:00:22,770
Em qualquer caso, isso nos leva ao tema desta palestra, População de Mangusto.

5
00:00:22,770 --> 00:00:25,120
O que exatamente é a população de Mangusto e

6
00:00:25,120 --> 00:00:29,800
como é útil em nossa aplicação expressa?

7
00:00:29,800 --> 00:00:31,190
Vamos falar sobre isso a seguir.

8
00:00:33,100 --> 00:00:38,275
Como percebemos, os bancos de dados de documentos, os bancos de dados NoSQL,

9
00:00:38,275 --> 00:00:41,767
não são projetados com relações em mente.

10
00:00:41,767 --> 00:00:46,570
Tudo o que você precisa em um documento é armazenado completamente dentro do documento.

11
00:00:46,570 --> 00:00:53,650
Bem, essa é praticamente a maneira como as coisas funcionam com bancos de dados NoSQL como MongoDB.

12
00:00:53,650 --> 00:00:58,490
Então você não tem suporte para relações que você pode estar

13
00:00:58,490 --> 00:01:03,065
mais familiarizado com o mundo do banco de dados relacional.

14
00:01:03,065 --> 00:01:08,060
Onde você tem registros e, em seguida, registros podem fazer referência a outros registros e assim por diante.

15
00:01:08,060 --> 00:01:12,510
E então você faz junções, a fim de juntar as informações dos registros e assim por diante.

16
00:01:12,510 --> 00:01:17,030
Portanto, esse tipo de suporte não existe em bancos de dados NoSQL,

17
00:01:17,030 --> 00:01:19,010
pelo menos em grande medida.

18
00:01:19,010 --> 00:01:25,120
MongoDB tomou alguns passos nessa direção, mesmo com os bancos de dados NoSQL.

19
00:01:25,120 --> 00:01:31,030
Mas, em geral, bancos de dados de documentos esperam que todos os documentos sejam autônomos.

20
00:01:31,030 --> 00:01:36,740
Então, o que significa que todas as informações necessárias estão dentro do mesmo documento.

21
00:01:36,740 --> 00:01:41,270
Agora, é claro, há situações em que você tem outros documentos que

22
00:01:41,270 --> 00:01:43,657
já continha as informações.

23
00:01:43,657 --> 00:01:47,561
E talvez você queira extrair essas informações para o documento existente, em

24
00:01:47,561 --> 00:01:50,580
vez de duplicar essas informações.

25
00:01:50,580 --> 00:01:57,390
Então este é o lugar onde MongoDB ou Mangusto,

26
00:01:57,390 --> 00:02:04,290
permite que você armazene referências a outros documentos dentro de um documento atual.

27
00:02:04,290 --> 00:02:08,953
A referência ao outro documento é feita usando o ObjectID desse

28
00:02:08,953 --> 00:02:10,125
outro documento.

29
00:02:10,125 --> 00:02:14,773
Agora, se esse for o caso, então Mangusto permite que você execute uma maneira de

30
00:02:14,773 --> 00:02:19,588
pegar as informações do outro documento e, em seguida, anexá-lo

31
00:02:19,588 --> 00:02:25,010
dentro do documento correto usando o apoio da população Mangusto.

32
00:02:25,010 --> 00:02:28,230
É isso que discutiremos com um pouco mais de pormenor.

33
00:02:28,230 --> 00:02:33,227
O próprio Mangusto, como percebemos, sendo um módulo construído

34
00:02:33,227 --> 00:02:38,336
sobre o MongoDB, não tem suporte explícito para

35
00:02:38,336 --> 00:02:43,135
junções, a maneira como falamos sobre junções no mundo SQL.

36
00:02:43,135 --> 00:02:48,471
Para entender como essa referência do outro documento em um documento nos ajuda e

37
00:02:48,471 --> 00:02:53,210
como ele está realmente estruturado, vamos dar uma olhada em um exemplo.

38
00:02:53,210 --> 00:02:58,420
Neste exemplo, vamos olhar para o documento de pratos que

39
00:02:58,420 --> 00:03:01,210
temos usado em nosso exercício.

40
00:03:01,210 --> 00:03:04,540
Nos documentos de pratos que armazenamos no lado do servidor,

41
00:03:04,540 --> 00:03:07,590
notamos que também armazenamos os comentários.

42
00:03:07,590 --> 00:03:12,366
E dentro dos comentários, também armazenamos um campo de autor dentro dos comentários.

43
00:03:12,366 --> 00:03:16,750
E o campo autor contém explicitamente o nome da pessoa que

44
00:03:16,750 --> 00:03:19,890
enviou esse comentário específico.

45
00:03:19,890 --> 00:03:24,961
Agora, uma vez que já temos um documento

46
00:03:24,961 --> 00:03:30,453
de usuários dentro do nosso banco de dados, como vimos neste módulo.

47
00:03:30,453 --> 00:03:35,151
Nós tínhamos estendido nosso servidor especializado para suportar usuários e, assim,

48
00:03:35,151 --> 00:03:40,440
você pode registrar um usuário e que você pode autenticar usuários e assim por diante.

49
00:03:40,440 --> 00:03:45,790
Assim, o documento do usuário pode transportar informações adicionais sobre o usuário já.

50
00:03:46,810 --> 00:03:49,302
Então, quando um comentário é postado pelo usuário,

51
00:03:49,302 --> 00:03:53,043
em vez de armazenar o nome do usuário dentro do próprio comentário,

52
00:03:53,043 --> 00:03:57,360
por que não ter uma referência ao usuário específico que postou o comentário?

53
00:03:58,360 --> 00:04:02,570
Isso é útil não só em termos de ser capaz de

54
00:04:02,570 --> 00:04:07,680
lidar com o fato de que este comentário é publicado pelo usuário específico.

55
00:04:07,680 --> 00:04:13,934
Mais tarde, veremos que, se você precisar permitir que os usuários modifiquem ou

56
00:04:13,934 --> 00:04:19,126
excluam documentos, você pode querer restringir o tipo

57
00:04:19,126 --> 00:04:24,436
de operação de um usuário específico apenas aos comentários

58
00:04:24,436 --> 00:04:28,937
que esse usuário específico publicou anteriormente.

59
00:04:28,937 --> 00:04:36,649
Mesmo que estejamos usando sub-documentos dentro do nosso documento Mongo.

60
00:04:36,649 --> 00:04:42,292
Se pudermos fazer referência a outro documento no subdocumento usando ObjectIDs,

61
00:04:42,292 --> 00:04:45,415
então Mongo nos ajuda a fazer população dessas

62
00:04:45,415 --> 00:04:50,450
informações do outro documento para o documento atual.

63
00:04:50,450 --> 00:04:54,370
Então é aqui que a população de Mangusto vem em nosso resgate.

64
00:04:54,370 --> 00:04:57,770
Levando esta ideia mais longe, deixe-me mostrar-lhe um

65
00:04:57,770 --> 00:05:02,600
exemplo detalhado do esquema de comentários que definimos anteriormente.

66
00:05:02,600 --> 00:05:06,850
Então, no CommentSchema, já temos o campo de classificação e

67
00:05:06,850 --> 00:05:10,080
o campo de comentário que já especificamos lá.

68
00:05:10,080 --> 00:05:13,320
Também costumávamos ter o campo de autor anteriormente.

69
00:05:13,320 --> 00:05:18,133
Para o campo autor anteriormente, estávamos armazenando o autor como

70
00:05:18,133 --> 00:05:23,270
uma string e, O valor padrão também para o autor.

71
00:05:23,270 --> 00:05:28,285
Agora, ao armazenar o autor como uma string de tipo, se agora transformar

72
00:05:28,285 --> 00:05:34,200
o autor em um tipo de mongoose.schema.types.ObjectId.

73
00:05:34,200 --> 00:05:39,350
Então, o que significa que o campo autor agora irá conter um ObjectID,

74
00:05:39,350 --> 00:05:42,870
que é uma referência a um documento de usuário.

75
00:05:42,870 --> 00:05:46,090
Como você garante que isso está fazendo referência a um documento de usuário?

76
00:05:46,090 --> 00:05:51,500
Então é aqui que esta propriedade adicional chamada ref, que especifica que

77
00:05:51,500 --> 00:05:56,160
o esquema do documento que você está se referindo aqui é do tipo, o usuário,

78
00:05:56,160 --> 00:05:59,590
esquema e o modelo que já adicionamos anteriormente.

79
00:05:59,590 --> 00:06:05,144
Então, neste caso, o esquema de comentário agora é estendido para armazenar as informações do autor,

80
00:06:05,144 --> 00:06:08,706
mas as informações do autor estão em uma forma de ObjectId.

81
00:06:08,706 --> 00:06:15,480
Que é uma referência ao documento do usuário que já está armazenado em nosso banco de dados.

82
00:06:15,480 --> 00:06:17,750
Agora, como é que isto nos ajuda?

83
00:06:17,750 --> 00:06:22,667
É aqui que, como eu disse, a população de Mangusto vem em nossa ajuda.

84
00:06:22,667 --> 00:06:25,120
Então, como funciona a população de Mangusto?

85
00:06:25,120 --> 00:06:30,150
Com a população de Mangusto, a forma como a população de Mangusto funciona

86
00:06:30,150 --> 00:06:35,363
é que ele substitui automaticamente caminhos especificados dentro de um documento atual.

87
00:06:35,363 --> 00:06:40,850
Que tem referência a outro documento pelas informações desse outro documento.

88
00:06:40,850 --> 00:06:46,282
Portanto, no esquema de comentário, por exemplo, você tem um campo de autor que

89
00:06:46,282 --> 00:06:53,070
está se referindo ao ObjectId do documento de usuário que já está em seu banco de dados.

90
00:06:53,070 --> 00:06:58,963
Assim, com a população de Mangusto, quando você pedir Mangusto para preencher este documento prato, em

91
00:06:58,963 --> 00:07:03,820
seguida, ele irá preencher as informações sobre o autor no campo

92
00:07:03,820 --> 00:07:05,240
de comentários do documento do usuário.

93
00:07:05,240 --> 00:07:09,447
Assim, as informações sobre o autor específico que é referenciado lá serão

94
00:07:09,447 --> 00:07:12,130
obtidas e adicionadas ao seu documento prato.

95
00:07:12,130 --> 00:07:16,820
E o documento composto será construído e enviado de volta para você.

96
00:07:16,820 --> 00:07:19,370
Como garantimos que isso aconteça?

97
00:07:19,370 --> 00:07:25,020
É aqui que a referência cruzada com o ObjectID, como vimos, nos ajuda.

98
00:07:25,020 --> 00:07:30,890
Como é que a população realmente acontece em código?

99
00:07:30,890 --> 00:07:33,350
Dando uma olhada em como poderíamos preencher, por

100
00:07:33,350 --> 00:07:38,090
exemplo, o documento de pratos que acabamos de ver anteriormente.

101
00:07:38,090 --> 00:07:43,650
Mais cedo estávamos fazendo pratos.Encontre para encontrar todos os pratos em nosso banco de dados.

102
00:07:43,650 --> 00:07:48,645
Agora, uma vez que você encontrar o documento Pratos, então você pode dizer preencher.

103
00:07:48,645 --> 00:07:52,647
E, em seguida, forneça dentro do preenchimento, como parâmetro,

104
00:07:52,647 --> 00:07:56,130
o campo específico que precisa ser preenchido.

105
00:07:56,130 --> 00:07:59,380
Então, aqui estamos especificando comentários.author.

106
00:07:59,380 --> 00:08:02,270
Agora a expectativa é que o campo comments.author é

107
00:08:02,270 --> 00:08:06,550
realmente um OjectId que faz referência ao documento do usuário.

108
00:08:06,550 --> 00:08:10,502
E é assim que já configuramos nosso esquema de comentários.

109
00:08:10,502 --> 00:08:16,418
Então esta chamada de preenchimento que realizamos aqui irá então

110
00:08:16,418 --> 00:08:24,937
buscar do banco de dados cada registro do autor individual ou o registro do usuário.

111
00:08:24,937 --> 00:08:27,457
E, em seguida, pegue esse documento de usuário e

112
00:08:27,457 --> 00:08:33,505
preencha-o no documento de pratos para construir o documento composto a partir daqui.

113
00:08:33,505 --> 00:08:35,525
E depois disso,

114
00:08:35,525 --> 00:08:39,579
é claro, há alguns manipulação subsequente de dados que você obteve.

115
00:08:39,579 --> 00:08:44,640
E, em seguida, responder ou retornar os dados para o cliente pode ocorrer neste momento.

116
00:08:44,640 --> 00:08:49,110
Mas é claro, deixe-me avisá-lo que esta operação de população

117
00:08:49,110 --> 00:08:52,020
não é uma tarefa fácil para o servidor fazer.

118
00:08:52,020 --> 00:08:56,825
Porque cada prato, você terá que examinar cada comentário.

119
00:08:56,825 --> 00:09:01,385
Então, para cada comentário, então você precisa descobrir seu ObjectID para

120
00:09:01,385 --> 00:09:02,034
o usuário.

121
00:09:02,034 --> 00:09:04,580
Em seguida, você vai buscar o documento do usuário e

122
00:09:04,580 --> 00:09:07,203
, em seguida, preenchê-lo dentro do documento prato.

123
00:09:07,203 --> 00:09:09,329
E, em seguida, isso tem que ser repetido para

124
00:09:09,329 --> 00:09:13,113
cada comentário que está contido no documento Dishes.

125
00:09:13,113 --> 00:09:18,437
Isso significa essencialmente que vai demorar muito mais tempo para o lado do servidor

126
00:09:18,437 --> 00:09:23,720
para concluir a solicitação e enviar de volta as informações para o lado do cliente.

127
00:09:23,720 --> 00:09:31,020
Então eu sugiro que você deve usar povoar muito judiciosamente.

128
00:09:31,020 --> 00:09:35,410
Você deve usá-lo apenas em circunstâncias em que você realmente precisa dessa informação.

129
00:09:36,590 --> 00:09:42,529
Se, por exemplo, você está simplesmente construindo o menu para o seu restaurante.

130
00:09:42,529 --> 00:09:46,522
Quando você está apenas construindo o menu para o seu restaurante,

131
00:09:46,522 --> 00:09:51,267
você pode realmente não precisar preencher as informações sobre o autor de cada

132
00:09:51,267 --> 00:09:54,010
comentário no documento de comentário em tudo.

133
00:09:54,010 --> 00:09:57,270
Porque quando você está apenas renderizando o menu para o seu restaurante,

134
00:09:57,270 --> 00:10:01,730
você não vai estar mostrando os comentários para esse prato específico.

135
00:10:01,730 --> 00:10:06,457
Mas, em vez disso, se o usuário estiver examinando um prato específico e

136
00:10:06,457 --> 00:10:09,804
quiser ver os comentários nesse ponto,

137
00:10:09,804 --> 00:10:13,660
você pode querer executar uma solicitação do lado do servidor.

138
00:10:13,660 --> 00:10:19,383
E, em seguida, buscar as informações do comentário com as outras informações do autor

139
00:10:19,383 --> 00:10:24,540
preenchidas e obtê-lo para uso dentro do lado do nosso cliente.

140
00:10:24,540 --> 00:10:30,240
Então, novamente, popular é uma maneira maravilhosa de fazer as coisas quando necessário,

141
00:10:30,240 --> 00:10:35,610
mas usá-lo muito judicialmente, somente quando você realmente precisa das informações.

142
00:10:35,610 --> 00:10:38,370
Então essa flexibilidade que povoam

143
00:10:38,370 --> 00:10:42,540
nos fornece é o fato de que não precisamos preencher quando não precisamos.

144
00:10:42,540 --> 00:10:46,990
Mas podemos preencher a informação quando realmente precisamos dessa informação.

145
00:10:48,030 --> 00:10:51,450
Com esta rápida compreensão da população de Mangusto,

146
00:10:51,450 --> 00:10:57,280
vamos passar para o exercício onde vamos modificar o esquema de pratos,

147
00:10:57,280 --> 00:10:59,840
o esquema de comentários dentro do esquema de pratos.

148
00:10:59,840 --> 00:11:04,730
E, em seguida, usar Mongoose populate para preencher a informação dentro de nossos pratos

149
00:11:04,730 --> 00:11:09,255
quando estamos devolvendo a informação do prato para o lado do servidor.

150
00:11:09,255 --> 00:11:15,745
Além disso, isso também implica que quando um comentário está sendo adicionado a um prato específico,

151
00:11:16,775 --> 00:11:22,210
o autor da informação do comentário deve ser capturado no lado do servidor.

152
00:11:22,210 --> 00:11:26,079
Agora, acontece que a forma como desenvolvemos nossos servidores,

153
00:11:26,079 --> 00:11:29,740
já temos essa informação sendo fornecida para nós.

154
00:11:29,740 --> 00:11:34,870
Quando autenticamos o usuário, as informações do usuário já são carregadas em cada

155
00:11:34,870 --> 00:11:37,580
solicitação que vem do lado do cliente.

156
00:11:37,580 --> 00:11:41,200
E assim eles usam que as informações do usuário estão disponíveis para nós.

157
00:11:41,200 --> 00:11:46,170
Então, quando estamos postando o comentário no lado do servidor, vamos também

158
00:11:46,170 --> 00:11:52,370
capturar o ID do usuário e, em seguida, armazená-lo no campo autor do esquema de comentário.

159
00:11:52,370 --> 00:11:55,430
Isso deve ser feito automaticamente no lado do servidor.

160
00:11:55,430 --> 00:12:00,740
O cliente não deve ter permissão para preencher o campo de autor explicitamente.

161
00:12:00,740 --> 00:12:04,348
Mas o lado do servidor deve validar o usuário e somente para

162
00:12:04,348 --> 00:12:10,020
usuários que estão conectados, você permitiria que eles, em primeiro lugar, postem comentários.

163
00:12:10,020 --> 00:12:12,688
E então, quando eles publicarem comentários,

164
00:12:12,688 --> 00:12:18,392
você preencherá automaticamente o campo de autor desse documento de comentário

165
00:12:18,392 --> 00:12:23,740
substituindo o campo de autor pelo ObjectID do usuário.

166
00:12:23,740 --> 00:12:25,920
Agora, no exercício, você vai me ver fazendo isso.

167
00:12:25,920 --> 00:12:30,780
Então cuidado com aquela coisa específica no exercício.

168
00:12:30,780 --> 00:12:33,245
Com isso, completamos esta palestra,

169
00:12:33,245 --> 00:12:38,109
vamos prosseguir para o exercício para examinar o uso da população de Mangusto.

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