Publicación / suscripción de múltiples subconjuntos de la misma colección de servidores

EDITAR: esta pregunta, algunas de las respuestas y algunos de los comentarios contienen mucha información errónea. VerCómo funcionan las colecciones, publicaciones y suscripciones de Meteor. para una comprensión precisa de la publicación y la suscripción a múltiples subconjuntos de la misma colección de servidores.

¿Cómo se hace para publicar diferentes subconjuntos (o "vistas") de una sola colección en el servidor como múltiples colecciones en el cliente?

Aquí hay un pseudocódigo para ayudar a ilustrar mi pregunta:

items colección en el servidor

Supongamos que tengo unitems Recopilación en el servidor con millones de registros. Supongamos también que:

50 registros tienen laenabled propiedad establecida entrue, y;100 registros tienen laprocessed propiedad establecida entrue.

Todos los demás están configurados parafalse.

items:
{
    "_id": "uniqueid1",
    "title": "item #1",
    "enabled": false,
    "processed": false
},
{
    "_id": "uniqueid2",
    "title": "item #2",
    "enabled": false,
    "processed": true
},
...
{
    "_id": "uniqueid458734958",
    "title": "item #458734958",
    "enabled": true,
    "processed": true
}
Código de servidor

Publicemos dos "vistas" de la misma colección de servidores. Uno enviará un cursor hacia abajo con 50 registros y el otro enviará un cursor hacia abajo con 100 registros. Hay más de 458 millones de registros en esta base de datos ficticia del servidor, y el cliente no necesita conocerlos (de hecho, enviarlos a todos probablemente llevaría varias horas en este ejemplo):

var Items = new Meteor.Collection("items");

Meteor.publish("enabled_items", function () {
    // Only 50 "Items" have enabled set to true
    return Items.find({enabled: true});
});

Meteor.publish("processed_items", function () {
    // Only 100 "Items" have processed set to true
    return Items.find({processed: true});
});
Codigo del cliente

Para admitir la técnica de compensación de latencia, nos vemos obligados a declarar una sola colección.Items en el cliente. Debería hacerse evidente dónde está la falla: ¿cómo se diferencia uno deItems paraenabled_items yItems paraprocessed_items?

var Items = new Meteor.Collection("items");

Meteor.subscribe("enabled_items", function () {
    // This will output 50, fine
    console.log(Items.find().count());
});

Meteor.subscribe("processed_items", function () {
    // This will also output 50, since we have no choice but to use
    // the same "Items" collection.
    console.log(Items.find().count());
});

Mi solución actual involucra el parche de mono _publishCursor para permitir el uso del nombre de suscripción en lugar del nombre de colección. Pero eso no hará ninguna compensación de latencia. Cada escritura tiene que redondear al servidor:

// On the client:
var EnabledItems = new Meteor.Collection("enabled_items");
var ProcessedItems = new Meteor.Collection("processed_items");

Con el parche de mono en su lugar, esto funcionará. Pero vaya al modo Desconectado y los cambios no aparecerán en el cliente de inmediato; tendremos que estar conectados al servidor para ver los cambios.

¿Cuál es el enfoque correcto?

EDIT: Acabo de volver a visitar este hilo y me doy cuenta de que, en su forma actual, mis preguntas y respuestas y una gran cantidad de comentarios conllevan mucha información errónea.

Lo que se reduce a esto es que entendí mal la relación publicación-suscripción. Pensé que cuando publicaba un cursor, aterrizaría en el cliente como una colección separada de otros cursores publicados que se originaron en la misma colección de servidores. Esto simplemente no es cómo funciona. La idea es que tanto el cliente como el servidor tengan las mismas colecciones, pero es lo que esen Las colecciones que se diferencian. Los contratos pub-sub negocian qué documentos terminan en el cliente. La respuesta de Tom es técnicamente correcta, pero faltaban algunos detalles para cambiar mis suposiciones. Respondí una pregunta similar a la mía en otro subproceso SO basado en la explicación de Tom, pero teniendo en cuenta mi malentendido original del pub-sub de Meteor:Meteor publica / suscribe estrategias para colecciones únicas del lado del cliente

Espero que esto ayude a aquellos que se encuentran en este hilo y salgan más confundidos que cualquier otra cosa.

Respuestas a la pregunta(3)

Su respuesta a la pregunta