1
00:00:04,652 --> 00:00:11,190
Supongo que a estas alturas tu cabeza está infestada de mangostas, ¿o es mangansas?

2
00:00:11,190 --> 00:00:16,500
Bueno, no soy una especialidad inglesa, así que no tengo ni idea de lo que es el plural.

3
00:00:16,500 --> 00:00:22,770
En cualquier caso, eso nos lleva al tema de esta conferencia, Población mangosta.

4
00:00:22,770 --> 00:00:25,120
¿ Qué es exactamente la población de mangosta y

5
00:00:25,120 --> 00:00:29,800
cómo es útil en nuestra aplicación expresa?

6
00:00:29,800 --> 00:00:31,190
Hablemos de eso a continuación.

7
00:00:33,100 --> 00:00:38,275
Como nos dimos cuenta, las bases de datos de documentos, las bases de datos NoSQL,

8
00:00:38,275 --> 00:00:41,767
no están diseñadas teniendo en cuenta las relaciones.

9
00:00:41,767 --> 00:00:46,570
Todo lo que necesita en un documento se almacena completamente dentro del documento.

10
00:00:46,570 --> 00:00:53,650
Bueno, esa es más o menos la forma en que las cosas funcionan con bases de datos NoSQL como MongoDB.

11
00:00:53,650 --> 00:00:58,490
Por lo tanto, no tiene soporte para las relaciones

12
00:00:58,490 --> 00:01:03,065
con las que podría estar más familiarizado desde el mundo de la base de datos relacional.

13
00:01:03,065 --> 00:01:08,060
Donde tiene registros y, a continuación, registros pueden hacer referencia a otros registros y así sucesivamente.

14
00:01:08,060 --> 00:01:12,510
Y luego se une con el fin de unir la información de los registros y así sucesivamente.

15
00:01:12,510 --> 00:01:17,030
Entonces ese tipo de soporte no existe en las bases de datos NoSQL,

16
00:01:17,030 --> 00:01:19,010
al menos en gran medida.

17
00:01:19,010 --> 00:01:25,120
MongoDB ha dado algunos pasos en esa dirección, incluso con las bases de datos NoSQL.

18
00:01:25,120 --> 00:01:31,030
Pero, en general, las bases de datos de documentos esperan que todos los documentos sean autónomos.

19
00:01:31,030 --> 00:01:36,740
Entonces, lo que significa que toda la información que se requiere está dentro del mismo documento.

20
00:01:36,740 --> 00:01:41,270
Ahora, por supuesto, hay situaciones en las que tiene otros documentos que

21
00:01:41,270 --> 00:01:43,657
ya contenían la información.

22
00:01:43,657 --> 00:01:47,561
Y es posible que desee extraer esa información en el documento existente, en

23
00:01:47,561 --> 00:01:50,580
lugar de duplicarla.

24
00:01:50,580 --> 00:01:57,390
Así que aquí es donde MongoDB o Mangosta,

25
00:01:57,390 --> 00:02:04,290
le permite almacenar referencias a otros documentos dentro de un documento actual.

26
00:02:04,290 --> 00:02:08,953
La referencia al otro documento se realiza utilizando el ObjectID de ese

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

28
00:02:10,125 --> 00:02:14,773
Ahora bien, si ese es el caso, entonces Mangosta le permite realizar una forma de

29
00:02:14,773 --> 00:02:19,588
tomar la información del otro documento y luego

30
00:02:19,588 --> 00:02:25,010
adjuntarla dentro del documento correcto utilizando el apoyo poblacional de Mangosta.

31
00:02:25,010 --> 00:02:28,230
Eso es lo que discutiremos con un poco más de detalle.

32
00:02:28,230 --> 00:02:33,227
Mangoose en sí, como nos damos cuenta, al ser un módulo

33
00:02:33,227 --> 00:02:38,336
construido sobre MongoDB, no tiene soportes explícitos para

34
00:02:38,336 --> 00:02:43,135
uniones, la forma en que hablamos de uniones en el mundo SQL.

35
00:02:43,135 --> 00:02:48,471
Para entender cómo esta referencia al otro documento en un documento nos ayuda y

36
00:02:48,471 --> 00:02:53,210
cómo está realmente estructurado, echemos un vistazo a un ejemplo.

37
00:02:53,210 --> 00:02:58,420
En este ejemplo, veremos el documento de platos que

38
00:02:58,420 --> 00:03:01,210
hemos estado utilizando en nuestro ejercicio.

39
00:03:01,210 --> 00:03:04,540
En los documentos de platos que almacenamos en el lado del servidor,

40
00:03:04,540 --> 00:03:07,590
notamos que también almacenamos los comentarios.

41
00:03:07,590 --> 00:03:12,366
Y dentro de los comentarios, también almacenamos un campo de autor dentro de los comentarios.

42
00:03:12,366 --> 00:03:16,750
Y el campo autor contiene explícitamente el nombre de la persona que

43
00:03:16,750 --> 00:03:19,890
envió ese comentario específico.

44
00:03:19,890 --> 00:03:24,961
Ahora, ya que ya tenemos un documento de usuarios

45
00:03:24,961 --> 00:03:30,453
dentro de nuestra base de datos, como vimos en este módulo.

46
00:03:30,453 --> 00:03:35,151
Hemos ampliado nuestro servidor experto para apoyar a los usuarios y, por lo tanto,

47
00:03:35,151 --> 00:03:40,440
puede registrar un usuario y que puede autenticar usuarios y así sucesivamente.

48
00:03:40,440 --> 00:03:45,790
Por lo tanto, el documento de usuario puede llevar información adicional sobre el usuario ya.

49
00:03:46,810 --> 00:03:49,302
Y entonces, cuando un comentario es publicado por el usuario,

50
00:03:49,302 --> 00:03:53,043
en lugar de almacenar el nombre del usuario dentro del comentario en sí,

51
00:03:53,043 --> 00:03:57,360
¿por qué no tener una referencia al usuario específico que ha publicado el comentario?

52
00:03:58,360 --> 00:04:02,570
Esto es útil no solo en términos de poder

53
00:04:02,570 --> 00:04:07,680
lidiar con el hecho de que este comentario es publicado por el usuario específico.

54
00:04:07,680 --> 00:04:13,934
Más adelante, veremos que si necesita permitir que los usuarios modifiquen o

55
00:04:13,934 --> 00:04:19,126
eliminen documentos, puede que desee restringir el tipo

56
00:04:19,126 --> 00:04:24,436
de operación de un usuario específico solo a aquellos comentarios

57
00:04:24,436 --> 00:04:28,937
que ese usuario específico haya publicado anteriormente.

58
00:04:28,937 --> 00:04:36,649
A pesar de que estamos usando sub-documentos dentro de nuestro documento Mongo.

59
00:04:36,649 --> 00:04:42,292
Si podemos hacer referencia a otro documento en el subdocumento usando ObjectID,

60
00:04:42,292 --> 00:04:45,415
entonces Mongo nos ayuda a completar esta

61
00:04:45,415 --> 00:04:50,450
información desde el otro documento en el documento actual.

62
00:04:50,450 --> 00:04:54,370
Así que aquí es donde la población de mangosta viene a nuestro rescate.

63
00:04:54,370 --> 00:04:57,770
Tomando esta idea más allá, permítanme mostrarles un

64
00:04:57,770 --> 00:05:02,600
ejemplo detallado del esquema de comentarios que hemos definido anteriormente.

65
00:05:02,600 --> 00:05:06,850
Así que en el CommentSchema, ya tenemos el campo de calificación y

66
00:05:06,850 --> 00:05:10,080
el campo de comentario que ya hemos especificado allí.

67
00:05:10,080 --> 00:05:13,320
También solíamos tener el campo de autor antes.

68
00:05:13,320 --> 00:05:18,133
Para el campo autor anterior, estábamos almacenando el autor como

69
00:05:18,133 --> 00:05:23,270
una cadena y, El valor predeterminado también para el autor.

70
00:05:23,270 --> 00:05:28,285
Ahora en el almacenamiento del autor como una cadena de tipo, si ahora convertimos

71
00:05:28,285 --> 00:05:34,200
al autor en un tipo de Mongoose.schema.Types.objectID.

72
00:05:34,200 --> 00:05:39,350
Lo que significa que el campo autor ahora contendrá un ObjectID,

73
00:05:39,350 --> 00:05:42,870
que es una referencia a un documento de usuario.

74
00:05:42,870 --> 00:05:46,090
¿ Cómo se asegura de que esto hace referencia a un documento de usuario?

75
00:05:46,090 --> 00:05:51,500
Así que aquí es donde esta propiedad adicional llamada ref, que especifica que

76
00:05:51,500 --> 00:05:56,160
el esquema del documento al que se refiere aquí es del tipo, el usuario, el

77
00:05:56,160 --> 00:05:59,590
esquema y el modelo que ya hemos agregado anteriormente.

78
00:05:59,590 --> 00:06:05,144
Por lo tanto, en este caso, el esquema de comentarios se extiende ahora para almacenar la información

79
00:06:05,144 --> 00:06:08,706
del autor, pero la información del autor está en forma de ObjectID.

80
00:06:08,706 --> 00:06:15,480
Que es una referencia al documento de usuario que ya está almacenado en nuestra base de datos.

81
00:06:15,480 --> 00:06:17,750
Ahora, ¿cómo nos ayuda esto?

82
00:06:17,750 --> 00:06:22,667
Aquí es donde, como dije, la población de mangosta viene en nuestra ayuda.

83
00:06:22,667 --> 00:06:25,120
Entonces, ¿cómo funciona la población de mangosta?

84
00:06:25,120 --> 00:06:30,150
Con la población de mangosta, la forma en que funciona la población de mangosta

85
00:06:30,150 --> 00:06:35,363
es que reemplaza automáticamente las rutas especificadas dentro de un documento actual.

86
00:06:35,363 --> 00:06:40,850
Que tiene referencia a otro documento por la información de ese otro documento.

87
00:06:40,850 --> 00:06:46,282
Entonces, en el esquema de comentarios, por ejemplo, tiene un campo de autor que

88
00:06:46,282 --> 00:06:53,070
se refiere al ObjectID del documento de usuario que ya está en su base de datos.

89
00:06:53,070 --> 00:06:58,963
Así que con la población de mangosta, cuando le pide a mangosta que rellene este documento de plato,

90
00:06:58,963 --> 00:07:03,820
rellenará la información sobre el autor en el campo

91
00:07:03,820 --> 00:07:05,240
de comentario del documento de usuario.

92
00:07:05,240 --> 00:07:09,447
Por lo tanto, la información sobre el autor específico al que se hace referencia allí será

93
00:07:09,447 --> 00:07:12,130
recogida y agregada en su documento de plato.

94
00:07:12,130 --> 00:07:16,820
Y el documento compuesto será construido y luego enviado de vuelta a usted.

95
00:07:16,820 --> 00:07:19,370
¿ Cómo nos aseguramos de que esto suceda?

96
00:07:19,370 --> 00:07:25,020
Aquí es donde esa referencia cruzada con el ObjectID, como hemos visto, nos ayuda.

97
00:07:25,020 --> 00:07:30,890
¿ Cómo sucede realmente la población en el código?

98
00:07:30,890 --> 00:07:33,350
Echando un vistazo a cómo poblaríamos, por

99
00:07:33,350 --> 00:07:38,090
ejemplo, el documento de platos que acabamos de ver antes.

100
00:07:38,090 --> 00:07:43,650
Anteriormente estábamos haciendo platos.Encuentra para encontrar todos los platos en nuestra base de datos.

101
00:07:43,650 --> 00:07:48,645
Ahora, una vez que encuentre el documento Platos, entonces puede decir poblar.

102
00:07:48,645 --> 00:07:52,647
Y, a continuación, proporcione dentro del relleno, como parámetro,

103
00:07:52,647 --> 00:07:56,130
el campo específico que debe rellenarse.

104
00:07:56,130 --> 00:07:59,380
Así que aquí estamos especificando comments.author.

105
00:07:59,380 --> 00:08:02,270
Ahora la expectativa es que el campo comments.author es

106
00:08:02,270 --> 00:08:06,550
en realidad un OjectID que hace referencia al documento de usuario.

107
00:08:06,550 --> 00:08:10,502
Y así es como ya hemos configurado nuestro esquema de comentarios.

108
00:08:10,502 --> 00:08:16,418
Así que esta llamada de relleno que realizamos aquí irá y

109
00:08:16,418 --> 00:08:24,937
buscará de la base de datos el registro de cada autor individual o el registro del usuario.

110
00:08:24,937 --> 00:08:27,457
Y luego toma ese documento de usuario y

111
00:08:27,457 --> 00:08:33,505
lo rellena en el documento de platos para construir el documento compuesto desde aquí.

112
00:08:33,505 --> 00:08:35,525
Y luego, después de eso, por supuesto,

113
00:08:35,525 --> 00:08:39,579
hay un manejo posterior de los datos que ha obtenido.

114
00:08:39,579 --> 00:08:44,640
Y luego responder o devolver los datos al cliente puede tener lugar en este punto.

115
00:08:44,640 --> 00:08:49,110
Pero, por supuesto, permítanme advertirles que esta operación de población

116
00:08:49,110 --> 00:08:52,020
no es una tarea fácil para el servidor.

117
00:08:52,020 --> 00:08:56,825
Debido a que cada plato, tendrá que examinar todos y cada uno de los comentarios.

118
00:08:56,825 --> 00:09:01,385
Luego, para todos y cada uno de los comentarios, entonces necesita averiguar su ObjectID para

119
00:09:01,385 --> 00:09:02,034
el usuario.

120
00:09:02,034 --> 00:09:04,580
Luego ve a buscar ese documento de usuario y

121
00:09:04,580 --> 00:09:07,203
luego lo rellena dentro del documento de plato.

122
00:09:07,203 --> 00:09:09,329
Y luego, eso tiene que repetirse para

123
00:09:09,329 --> 00:09:13,113
cada comentario que está contenido en ese documento de Platos.

124
00:09:13,113 --> 00:09:18,437
Básicamente significa que tomará mucho más tiempo para que el lado del servidor

125
00:09:18,437 --> 00:09:23,720
complete la solicitud y envíe la información al lado del cliente.

126
00:09:23,720 --> 00:09:31,020
Así que sugeriría que debería usar populate muy juiciosamente.

127
00:09:31,020 --> 00:09:35,410
Deberías usarlo solo en circunstancias en las que realmente necesites esa información.

128
00:09:36,590 --> 00:09:42,529
Si, por ejemplo, simplemente está construyendo el menú para su restaurante.

129
00:09:42,529 --> 00:09:46,522
Cuando estás construyendo el menú para tu restaurante,

130
00:09:46,522 --> 00:09:51,267
es posible que no necesites rellenar la información sobre el autor de cada

131
00:09:51,267 --> 00:09:54,010
comentario en el documento de comentario.

132
00:09:54,010 --> 00:09:57,270
Porque cuando solo estás renderizando el menú para tu restaurante,

133
00:09:57,270 --> 00:10:01,730
no vas a mostrar los comentarios de ese plato específico.

134
00:10:01,730 --> 00:10:06,457
Pero en cambio, si el usuario está examinando un plato específico y

135
00:10:06,457 --> 00:10:09,804
quiere ver los comentarios en ese punto, es posible que

136
00:10:09,804 --> 00:10:13,660
desee ejecutar una solicitud del lado del servidor.

137
00:10:13,660 --> 00:10:19,383
Y luego busque la información del comentario con la otra información del autor

138
00:10:19,383 --> 00:10:24,540
rellenada y obtenga esa información para su uso dentro de nuestro lado del cliente.

139
00:10:24,540 --> 00:10:30,240
De nuevo, poblar es una forma maravillosa de hacer las cosas cuando sea necesario,

140
00:10:30,240 --> 00:10:35,610
pero úsalo muy judicialmente, solo cuando realmente requiera la información.

141
00:10:35,610 --> 00:10:38,370
Así que esa flexibilidad que

142
00:10:38,370 --> 00:10:42,540
nos proporciona es el hecho de que no necesitamos poblar cuando no tenemos que hacerlo.

143
00:10:42,540 --> 00:10:46,990
Pero podemos rellenar la información cuando realmente necesitamos esa información.

144
00:10:48,030 --> 00:10:51,450
Con esta rápida comprensión de la población de Mangosta,

145
00:10:51,450 --> 00:10:57,280
pasemos al ejercicio donde modificaremos el esquema Platos,

146
00:10:57,280 --> 00:10:59,840
el esquema de comentarios dentro del esquema Platos.

147
00:10:59,840 --> 00:11:04,730
Y luego use mangosta poblar para poblar la información dentro de nuestros platos

148
00:11:04,730 --> 00:11:09,255
cuando estamos devolviendo la información del plato al lado del servidor.

149
00:11:09,255 --> 00:11:15,745
Además, esto también implica que cuando se agrega un comentario a un plato específico,

150
00:11:16,775 --> 00:11:22,210
el autor de la información del comentario tiene que ser capturado en el lado del servidor.

151
00:11:22,210 --> 00:11:26,079
Ahora, sucede que la forma en que hemos desarrollado nuestros servidores,

152
00:11:26,079 --> 00:11:29,740
ya tenemos esta información siendo proporcionada para nosotros.

153
00:11:29,740 --> 00:11:34,870
Cuando autenticamos al usuario, la información del usuario ya se carga en cada

154
00:11:34,870 --> 00:11:37,580
solicitud que viene desde el lado del cliente.

155
00:11:37,580 --> 00:11:41,200
Y por eso usan esa información de usuario disponible para nosotros.

156
00:11:41,200 --> 00:11:46,170
Por lo tanto, cuando estamos publicando el comentario en el lado del servidor, también

157
00:11:46,170 --> 00:11:52,370
capturaremos el ID del usuario y luego lo almacenaremos en el campo de autor del esquema de comentarios.

158
00:11:52,370 --> 00:11:55,430
Esto debe hacerse automáticamente en el lado del servidor.

159
00:11:55,430 --> 00:12:00,740
No se debe permitir al cliente rellenar el campo autor de forma explícita.

160
00:12:00,740 --> 00:12:04,348
Pero el lado del servidor debe validar al usuario y solo para

161
00:12:04,348 --> 00:12:10,020
los usuarios que hayan iniciado sesión, les permitiría, en primer lugar, publicar comentarios.

162
00:12:10,020 --> 00:12:12,688
Y luego, cuando publiquen comentarios,

163
00:12:12,688 --> 00:12:18,392
rellenará automáticamente el campo de autor para ese documento de comentario

164
00:12:18,392 --> 00:12:23,740
sustituyendo el campo autor por el ID de objeto del usuario.

165
00:12:23,740 --> 00:12:25,920
Ahora, en el ejercicio, me verás haciendo eso.

166
00:12:25,920 --> 00:12:30,780
Así que ten cuidado con esa cosa específica en el ejercicio.

167
00:12:30,780 --> 00:12:33,245
Con esto, completamos esta conferencia,

168
00:12:33,245 --> 00:12:38,109
pasemos al ejercicio para examinar el uso de la población de mangosta.

169
00:12:38,109 --> 00:12:44,079
[ MÚSICA]