sql >> Base de Datos >  >> NoSQL >> MongoDB

Meteor:¿diferencia entre nombres de colecciones, variables, publicaciones y suscripciones?

Distingamos entre los diferentes nombres con los que podría tener que lidiar al programar 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 usar mayúsculas.
  • Nombres de colecciones , como 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 publicaciones y suscripciones , usado 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 hacer coincidir en el modelo de datos de Meteor:

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

El nombre de una 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 por qué tener nada que ver con el nombre de la suscripción. De hecho, se pueden enviar múltiples cursores en una publicación o una colección sobre diferentes publicaciones o incluso múltiples suscripciones por publicación , que aparecen combinados como uno solo 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 suele ver en las demostraciones sencillas de Meteor.

    En 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 las Posts colección (que se llama posts en la base de datos) usando 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 las Posts colección así como los Comments colección usando una sola publicación llamada postsAndComments . Este tipo de publicación es muy adecuado 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. Múltiples publicaciones 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 servidor y 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 envía tanto las 10 publicaciones con más comentarios como las 10 publicaciones más nuevas en el sitio al usuario, que ve ambos conjuntos de datos combinados en una sola Posts. recopilación. Si una de las publicaciones más recientes es también una publicación con la mayor cantidad de comentarios o viceversa, las Posts colección contendrá menos de 20 artículos. Este es un ejemplo de cómo el modelo de datos en Meteor le permite realizar poderosas operaciones de combinación de datos sin implementar los detalles usted mismo.

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

    En servidor y 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 para que ambos aparezcan en las posts recopilación. Este modelo es conveniente cuando tiene varios cálculos diferentes que analizan diferentes porciones de sus datos y pueden actualizarse dinámicamente. Tenga en cuenta que cuando se suscribe dentro de un Deps.autorun(...) , Meteor llama a stop() en cualquier identificador de suscripción anterior con el mismo nombre automáticamente, pero si está utilizando estas suscripciones fuera de un autorun tendrá que detenerlos usted mismo. A partir de ahora, no puedes hacer dos suscripciones con el mismo nombre dentro de un autorun cálculo, porque Meteor no puede diferenciarlos.

  5. Impulsar 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 ninguna 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 recientes de Posts colección en el servidor (llamada posts en la base de datos) a NewPosts colección 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 muchas 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. Sin embargo, tenga cuidado, ya que debe desactivar manualmente observe maneja y marca 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 está desactualizada). Por supuesto, puede combinar esto con las otras piezas anteriores para obtener potencialmente publicaciones muy matizadas y complicadas.

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