Supongo que a estas alturas tu cabeza está infestada de mangostas, ¿o es mangansas?
Bueno, no soy una especialidad inglesa, así que no tengo ni idea de lo que es el plural.
En cualquier caso, eso nos lleva al tema de esta conferencia, Población mangosta.
¿ Qué es exactamente la población de mangosta y
cómo es útil en nuestra aplicación expresa?
Hablemos de eso a continuación.
Como nos dimos cuenta, las bases de datos de documentos, las bases de datos NoSQL,
no están diseñadas teniendo en cuenta las relaciones.
Todo lo que necesita en un documento se almacena completamente dentro del documento.
Bueno, esa es más o menos la forma en que las cosas funcionan con bases de datos NoSQL como MongoDB.
Por lo tanto, no tiene soporte para las relaciones
con las que podría estar más familiarizado desde el mundo de la base de datos relacional.
Donde tiene registros y, a continuación, registros pueden hacer referencia a otros registros y así sucesivamente.
Y luego se une con el fin de unir la información de los registros y así sucesivamente.
Entonces ese tipo de soporte no existe en las bases de datos NoSQL,
al menos en gran medida.
MongoDB ha dado algunos pasos en esa dirección, incluso con las bases de datos NoSQL.
Pero, en general, las bases de datos de documentos esperan que todos los documentos sean autónomos.
Entonces, lo que significa que toda la información que se requiere está dentro del mismo documento.
Ahora, por supuesto, hay situaciones en las que tiene otros documentos que
ya contenían la información.
Y es posible que desee extraer esa información en el documento existente, en
lugar de duplicarla.
Así que aquí es donde MongoDB o Mangosta,
le permite almacenar referencias a otros documentos dentro de un documento actual.
La referencia al otro documento se realiza utilizando el ObjectID de ese
otro documento.
Ahora bien, si ese es el caso, entonces Mangosta le permite realizar una forma de
tomar la información del otro documento y luego
adjuntarla dentro del documento correcto utilizando el apoyo poblacional de Mangosta.
Eso es lo que discutiremos con un poco más de detalle.
Mangoose en sí, como nos damos cuenta, al ser un módulo
construido sobre MongoDB, no tiene soportes explícitos para
uniones, la forma en que hablamos de uniones en el mundo SQL.
Para entender cómo esta referencia al otro documento en un documento nos ayuda y
cómo está realmente estructurado, echemos un vistazo a un ejemplo.
En este ejemplo, veremos el documento de platos que
hemos estado utilizando en nuestro ejercicio.
En los documentos de platos que almacenamos en el lado del servidor,
notamos que también almacenamos los comentarios.
Y dentro de los comentarios, también almacenamos un campo de autor dentro de los comentarios.
Y el campo autor contiene explícitamente el nombre de la persona que
envió ese comentario específico.
Ahora, ya que ya tenemos un documento de usuarios
dentro de nuestra base de datos, como vimos en este módulo.
Hemos ampliado nuestro servidor experto para apoyar a los usuarios y, por lo tanto,
puede registrar un usuario y que puede autenticar usuarios y así sucesivamente.
Por lo tanto, el documento de usuario puede llevar información adicional sobre el usuario ya.
Y entonces, cuando un comentario es publicado por el usuario,
en lugar de almacenar el nombre del usuario dentro del comentario en sí,
¿por qué no tener una referencia al usuario específico que ha publicado el comentario?
Esto es útil no solo en términos de poder
lidiar con el hecho de que este comentario es publicado por el usuario específico.
Más adelante, veremos que si necesita permitir que los usuarios modifiquen o
eliminen documentos, puede que desee restringir el tipo
de operación de un usuario específico solo a aquellos comentarios
que ese usuario específico haya publicado anteriormente.
A pesar de que estamos usando sub-documentos dentro de nuestro documento Mongo.
Si podemos hacer referencia a otro documento en el subdocumento usando ObjectID,
entonces Mongo nos ayuda a completar esta
información desde el otro documento en el documento actual.
Así que aquí es donde la población de mangosta viene a nuestro rescate.
Tomando esta idea más allá, permítanme mostrarles un
ejemplo detallado del esquema de comentarios que hemos definido anteriormente.
Así que en el CommentSchema, ya tenemos el campo de calificación y
el campo de comentario que ya hemos especificado allí.
También solíamos tener el campo de autor antes.
Para el campo autor anterior, estábamos almacenando el autor como
una cadena y, El valor predeterminado también para el autor.
Ahora en el almacenamiento del autor como una cadena de tipo, si ahora convertimos
al autor en un tipo de Mongoose.schema.Types.objectID.
Lo que significa que el campo autor ahora contendrá un ObjectID,
que es una referencia a un documento de usuario.
¿ Cómo se asegura de que esto hace referencia a un documento de usuario?
Así que aquí es donde esta propiedad adicional llamada ref, que especifica que
el esquema del documento al que se refiere aquí es del tipo, el usuario, el
esquema y el modelo que ya hemos agregado anteriormente.
Por lo tanto, en este caso, el esquema de comentarios se extiende ahora para almacenar la información
del autor, pero la información del autor está en forma de ObjectID.
Que es una referencia al documento de usuario que ya está almacenado en nuestra base de datos.
Ahora, ¿cómo nos ayuda esto?
Aquí es donde, como dije, la población de mangosta viene en nuestra ayuda.
Entonces, ¿cómo funciona la población de mangosta?
Con la población de mangosta, la forma en que funciona la población de mangosta
es que reemplaza automáticamente las rutas especificadas dentro de un documento actual.
Que tiene referencia a otro documento por la información de ese otro documento.
Entonces, en el esquema de comentarios, por ejemplo, tiene un campo de autor que
se refiere al ObjectID del documento de usuario que ya está en su base de datos.
Así que con la población de mangosta, cuando le pide a mangosta que rellene este documento de plato,
rellenará la información sobre el autor en el campo
de comentario del documento de usuario.
Por lo tanto, la información sobre el autor específico al que se hace referencia allí será
recogida y agregada en su documento de plato.
Y el documento compuesto será construido y luego enviado de vuelta a usted.
¿ Cómo nos aseguramos de que esto suceda?
Aquí es donde esa referencia cruzada con el ObjectID, como hemos visto, nos ayuda.
¿ Cómo sucede realmente la población en el código?
Echando un vistazo a cómo poblaríamos, por
ejemplo, el documento de platos que acabamos de ver antes.
Anteriormente estábamos haciendo platos.Encuentra para encontrar todos los platos en nuestra base de datos.
Ahora, una vez que encuentre el documento Platos, entonces puede decir poblar.
Y, a continuación, proporcione dentro del relleno, como parámetro,
el campo específico que debe rellenarse.
Así que aquí estamos especificando comments.author.
Ahora la expectativa es que el campo comments.author es
en realidad un OjectID que hace referencia al documento de usuario.
Y así es como ya hemos configurado nuestro esquema de comentarios.
Así que esta llamada de relleno que realizamos aquí irá y
buscará de la base de datos el registro de cada autor individual o el registro del usuario.
Y luego toma ese documento de usuario y
lo rellena en el documento de platos para construir el documento compuesto desde aquí.
Y luego, después de eso, por supuesto,
hay un manejo posterior de los datos que ha obtenido.
Y luego responder o devolver los datos al cliente puede tener lugar en este punto.
Pero, por supuesto, permítanme advertirles que esta operación de población
no es una tarea fácil para el servidor.
Debido a que cada plato, tendrá que examinar todos y cada uno de los comentarios.
Luego, para todos y cada uno de los comentarios, entonces necesita averiguar su ObjectID para
el usuario.
Luego ve a buscar ese documento de usuario y
luego lo rellena dentro del documento de plato.
Y luego, eso tiene que repetirse para
cada comentario que está contenido en ese documento de Platos.
Básicamente significa que tomará mucho más tiempo para que el lado del servidor
complete la solicitud y envíe la información al lado del cliente.
Así que sugeriría que debería usar populate muy juiciosamente.
Deberías usarlo solo en circunstancias en las que realmente necesites esa información.
Si, por ejemplo, simplemente está construyendo el menú para su restaurante.
Cuando estás construyendo el menú para tu restaurante,
es posible que no necesites rellenar la información sobre el autor de cada
comentario en el documento de comentario.
Porque cuando solo estás renderizando el menú para tu restaurante,
no vas a mostrar los comentarios de ese plato específico.
Pero en cambio, si el usuario está examinando un plato específico y
quiere ver los comentarios en ese punto, es posible que
desee ejecutar una solicitud del lado del servidor.
Y luego busque la información del comentario con la otra información del autor
rellenada y obtenga esa información para su uso dentro de nuestro lado del cliente.
De nuevo, poblar es una forma maravillosa de hacer las cosas cuando sea necesario,
pero úsalo muy judicialmente, solo cuando realmente requiera la información.
Así que esa flexibilidad que
nos proporciona es el hecho de que no necesitamos poblar cuando no tenemos que hacerlo.
Pero podemos rellenar la información cuando realmente necesitamos esa información.
Con esta rápida comprensión de la población de Mangosta,
pasemos al ejercicio donde modificaremos el esquema Platos,
el esquema de comentarios dentro del esquema Platos.
Y luego use mangosta poblar para poblar la información dentro de nuestros platos
cuando estamos devolviendo la información del plato al lado del servidor.
Además, esto también implica que cuando se agrega un comentario a un plato específico,
el autor de la información del comentario tiene que ser capturado en el lado del servidor.
Ahora, sucede que la forma en que hemos desarrollado nuestros servidores,
ya tenemos esta información siendo proporcionada para nosotros.
Cuando autenticamos al usuario, la información del usuario ya se carga en cada
solicitud que viene desde el lado del cliente.
Y por eso usan esa información de usuario disponible para nosotros.
Por lo tanto, cuando estamos publicando el comentario en el lado del servidor, también
capturaremos el ID del usuario y luego lo almacenaremos en el campo de autor del esquema de comentarios.
Esto debe hacerse automáticamente en el lado del servidor.
No se debe permitir al cliente rellenar el campo autor de forma explícita.
Pero el lado del servidor debe validar al usuario y solo para
los usuarios que hayan iniciado sesión, les permitiría, en primer lugar, publicar comentarios.
Y luego, cuando publiquen comentarios,
rellenará automáticamente el campo de autor para ese documento de comentario
sustituyendo el campo autor por el ID de objeto del usuario.
Ahora, en el ejercicio, me verás haciendo eso.
Así que ten cuidado con esa cosa específica en el ejercicio.
Con esto, completamos esta conferencia,
pasemos al ejercicio para examinar el uso de la población de mangosta.
[ MÚSICA]