EDIT: this question, some of the answers, and some of the comments, contain a lot of misinformation. See как работают метеорные коллекции, публикации и подписки для точного понимания публикации и подписки на несколько подмножеств одной и той же коллекции серверов.

Как можно публиковать разные подмножества (или «представления») одной коллекции на сервере в виде нескольких коллекций на клиенте?

Вот некоторый псевдокод, чтобы проиллюстрировать мой вопрос:

items collection on the server

Предположим, что у меня естьitems Коллекция на сервере с миллионами записей. Также предположим, что:

50 records have the enabled property set to true, and; 100 records have the processed property set to true.

Все остальные настроены наfalse.

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
}

Server code

Давайте опубликуем два "представления" из той же коллекции серверов. Один отправит курсор с 50 записями, а другой отправит курсор с 100 записями. В этой фиктивной серверной базе данных содержится более 458 миллионов записей, и клиенту не нужно знать обо всех этих фактах (фактически, отправка их всех в этом примере, вероятно, займет несколько часов):

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});
});

Client code

Чтобы поддержать метод компенсации задержки, мы вынуждены объявить единый сборItems на клиенте. Должно стать очевидным, где недостаток: как можно различитьItems заenabled_items а такжеItems заprocessed_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());
});

Мое текущее решение включает в себя создание обезьяньего патча _publishCursor, позволяющего использовать имя подписки вместо имени коллекции. Но это не даст никакой компенсации за задержку. Каждая запись должна идти в оба конца на сервер:

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

С обезьяньим патчем на месте, это будет работать. Но перейдите в автономный режим, и изменения не появятся на клиенте сразу - нам нужно подключиться к серверу, чтобы увидеть изменения.

Какой правильный подход?

EDIT: I just revisited this thread and I realize that, as it stands, my question and answers and plethora of comments carry a lot of misinformation.

То, что сводится к тому, что я неправильно понял отношения публикации и подписки. Я думал, что когда вы публикуете курсор, он попадает на клиент как отдельную коллекцию от других опубликованных курсоров, созданных из той же коллекции серверов. Это просто не то, как это работает. Идея состоит в том, что и клиент, и сервер имеют одинаковые коллекции, но это то, чтоin коллекции, которые отличаются. Контракты pub-sub договариваются о том, какие документы попадают на клиента. Ответ Тома технически верен, но он упустил несколько деталей, чтобы перевернуть мои предположения. Я ответил на тот же вопрос, что и мой, в другой ветке SO, основываясь на объяснениях Тома, но имея в виду мое первоначальное недопонимание в пабе Meteor:Метеоритные стратегии публикации / подписки для уникальных коллекций на стороне клиента

Надеюсь, что это поможет тем, кто пересекает эту тему и уходит в замешательстве больше всего на свете!