mongodb - insecure - Meteor: ¿diferencia entre nombres para colecciones, variables, publicaciones y suscripciones?

meteor publish subscribe example

Question

En los ejemplos de Discover Meteor, ¿cuál es la diferencia entre "publicaciones" y "publicaciones"? ¿Por qué cuando hacemos una inserción desde el servidor usamos "publicaciones" pero cuando consultamos desde el navegador usamos "Publicaciones"? ¿No se confundiría el sistema con las diferencias de casos?

Veo la asignación de variable para las publicaciones de los clientes a las publicaciones del servidor en posts.js. ¿Es una notación convencional capitalizar al cliente y usar letras mayúsculas para el servidor?

Posts = new Meteor.Collection(''posts'')

¿Por qué server / fixtures.js usa "Publicaciones"? Estaba bajo la suposición de que consultamos "Publicaciones" en el navegador (cliente) y usamos "publicaciones" en el servidor, como hicimos en meteor mongo. Entonces, ¿por qué ahora estamos usando Publicaciones en el servidor?

Answer 1

Usted decide las convenciones de nomenclatura, y el meteorito no se preocupa.

Publicaciones se convierte en una colección de documentos del servidor mongo. Encuentra publicaciones llamando a Posts.find ({author: ''jim}). En el ejemplo que escribió, se le está diciendo a meteorito que llame internamente a esa colección ''publicaciones''. Espero que esto sea fácil de recordar si los nombres son similares ...

Debe haber una forma de expresar y rastrear qué información está disponible para los clientes. A veces puede haber múltiples conjuntos de información, de diversos detalles. Ejemplo: un resumen para una lista de títulos, pero detalles para un documento en particular. A menudo, estos también se denominan ''publicaciones'', por lo que puede ser inicialmente confuso:

Meteor.publish "posts", ->  # on server
  Posts.find()  

y entonces

dbs.subscriptions.posts = Meteor.subscribe ''posts''  # on client

los nombres de publicación y suscripción deben coincidir, pero todos pueden nombrarse así:

PostsDB = new Meteor.Collection(''postdocumentsonserver'')

entonces en mongo tendrías que escribir

db.postdocumentsonserver.find()

pero de lo contrario nunca tendrá que preocuparse por ''postdocumentsonserver''. Entonces

Meteor.publish "post_titles", ->
  PostsDB.find({},{fields:{name:1}})  

pareo

dbs.subscriptions.post_titles = Meteor.subscribe ''post_titles''

Answer 2

Vamos a distinguir entre los diferentes nombres con los que deberías lidiar cuando programes Meteor:

• Nombres de variables , como Posts = new Meteor.Collection(...) . Estos se usan solo para que su código sepa cómo acceder a esta variable. Meteor no sabe ni le importa lo que es, aunque la convención es capitalizar.
• Nombres de colecciones , como la new Meteor.Collection("posts") . Esto se asigna al nombre de una colección MongoDB (en el servidor) o una colección minimongo (en el cliente).
• Nombres de publicación y suscripción , utilizados en Meteor.publish("foo", ...) o Meteor.subscribe("foo") . Estos tienen que coincidir para que el cliente se suscriba a algunos datos en el servidor.

Hay dos cosas que debe coincidir en el modelo de datos Meteor:

1. Nombres de publicaciones y sus suscripciones correspondientes
2. (generalmente) Nombres de colecciones en el cliente y servidor, si usa el modelo de colección predeterminado

Un nombre de suscripción siempre debe coincidir con el nombre de una publicación. Sin embargo, las colecciones que se envían para una suscripción determinada no tienen que ver con el nombre de la suscripción. De hecho, uno puede enviar múltiples cursores en una publicación o colección sobre diferentes publicaciones o incluso múltiples suscripciones por publicación , que aparecen fusionadas como una sola en el cliente. También puede tener diferentes nombres de colección en el servidor y el cliente; sigue leyendo ...

Repasemos los diferentes casos:

1. Modelo de suscripción simple . Este es el que normalmente ves en las demostraciones directas de Meteor.

   En el cliente y servidor,

   Posts = new Meteor.Collection("posts");

   Solo en el servidor:

   Meteor.publish("postsPub", function() { 
       return Posts.find() 
   });

   Solo en el cliente:

   Meteor.subscribe("postsPub")

   Esto sincroniza la colección Posts (que se denomina posts en la base de datos) utilizando la publicación llamada postsPub .

2. Múltiples colecciones en una publicación . Puede enviar múltiples cursores para una sola publicación, usando una matriz.

   En cliente y servidor:

   Posts = new Meteor.Collection("posts");
   Comments = new Meteor.Collection("comments");

   Solo en el servidor:

   Meteor.publish("postsAndComments", function() { 
       return [ 
           Posts.find(), 
           Comments.find() 
       ]; 
   });

   Solo en el cliente:

   Meteor.subscribe("postsAndComments");

   Esto sincroniza la colección de Posts , así como la colección de Comments , utilizando una sola publicación llamada postsAndComments . Este tipo de publicación es muy adecuada para datos relacionales; por ejemplo, donde es posible que desee publicar solo ciertas publicaciones y los comentarios asociados solo con esas publicaciones. Vea un paquete que puede construir estos cursores automáticamente .

3. Publicaciones múltiples para una sola colección . Puede usar múltiples publicaciones para enviar diferentes segmentos de datos para una sola colección que Meteor fusiona automáticamente.

   En el servidor y el cliente:

   Posts = new Meteor.Collection("posts");

   Solo en el servidor:

   Meteor.publish("top10Posts", function() { 
       return Posts.find({}, {
           sort: {comments: -1}, 
           limit: 10
       });
   });        
   Meteor.publish("newest10Posts", function() { 
       return Posts.find({}, {
           sort: {timestamp: -1},
           limit: 10
       }); 
   });

   Solo en el cliente:

   Meteor.subscribe("top10Posts");
   Meteor.subscribe("newest10Posts");

   Esto lleva al usuario tanto a las 10 publicaciones con la mayor cantidad de comentarios como a las 10 publicaciones más recientes en el sitio, que ve a ambos conjuntos de datos fusionados en una sola colección de Posts . Si una de las publicaciones más recientes también es una publicación con más comentarios o viceversa, la colección de publicaciones contendrá menos de 20 elementos. Este es un ejemplo de cómo el modelo de datos en Meteor le permite realizar operaciones de fusión de datos poderosas sin implementar los detalles usted mismo.

4. Múltiples suscripciones por publicación. Puede obtener múltiples conjuntos de datos de la misma publicación usando diferentes argumentos.

   En el servidor y el cliente:

   Posts = new Meteor.Collection("posts");

   Solo en el servidor:

   Meteor.publish("postsByUser", function(user) { 
       return Posts.find({
           userId: user
       });
   });        

   Solo en el cliente:

   Meteor.subscribe("postsByUser", "fooUser");
   Meteor.subscribe("postsByUser", "barUser");

   Esto hace que las publicaciones de fooUser y barUser aparezcan en la colección de posts . Este modelo es conveniente cuando tiene varios cómputos diferentes que están mirando diferentes sectores de sus datos y pueden actualizarse dinámicamente. Tenga en cuenta que cuando se suscribe dentro de Deps.autorun(...) , Meteor llama a stop() en cualquier identificador de suscripción anterior con el mismo nombre de forma automática, pero si utiliza estas suscripciones fuera de una autorun , tendrá que detenerlas usted mismo . A partir de ahora, no puede hacer dos suscripciones con el mismo nombre dentro de un cómputo de autorun , porque Meteor no puede diferenciarlas.

5. Empujando datos arbitrarios sobre una publicación. Puede personalizar completamente las publicaciones para que no requieran los mismos nombres de colección en el servidor y el cliente. De hecho, el servidor puede publicar datos que no están respaldados por una colección. Para hacer esto, puede usar la API para las funciones de publicación .

   Solo en el servidor:

   Posts = new Meteor.Collection("posts"); 
   
   Meteor.publish("newPostsPub", function() {
       var sub = this;
       var subHandle = null;
   
       subHandle = Posts.find({}, {
           sort: {timestamp: -1},
           limit: 10
       })
       .observeChanges({
           added: function(id, fields) {
               sub.added("newposts", id, fields);            
           },
           changed: function(id, fields) {
               sub.changed("newposts", id, fields);            
           },
           removed: function(id) {
               sub.removed("newposts", id);
           }
       });
   
       sub.ready();
   
       sub.onStop(function() {
           subHandle.stop();
       })    
   });

   Solo en el cliente:

   NewPosts = new Meteor.Collection("newposts");
   
   Meteor.subscribe("newPostsPub");

   Esto sincroniza las 10 publicaciones más nuevas de la colección Posts en el servidor (llamadas posts en la base de datos) a la colección NewPosts en el cliente (llamada newposts en minimongo) usando la publicación / suscripción llamada newPostsPub . Tenga en cuenta que observeChanges difiere de observe , que puede hacer un montón de otras cosas .

   El código parece complicado, pero cuando devuelve un cursor dentro de una función de publicación, este es básicamente el código que Meteor está generando detrás de escena. Escribir publicaciones de esta manera le da mucho más control sobre lo que se envía y lo que no se envía al cliente. Tenga cuidado, ya que debe desactivar manualmente los identificadores y marcar cuando la suscripción esté lista. Para obtener más información, consulte la descripción de Matt Debergalis de este proceso (sin embargo, esa publicación no está actualizada). Por supuesto, puede combinar esto con las otras piezas anteriores para obtener potencialmente publicaciones muy matizadas y complicadas.

Perdón por el ensayo :-) pero muchas personas se confunden con esto y pensé que sería útil describir todos los casos.