EDIT: to pytanie, niektóre odpowiedzi i niektóre komentarze zawierają wiele dezinformacji. Widziećjak działają kolekcje Meteor, publikacje i subskrypcje dla dokładnego zrozumienia publikowania i subskrybowania wielu podzbiorów tej samej kolekcji serwerów.

W jaki sposób można publikować różne podzbiory (lub „widoki”) pojedynczej kolekcji na serwerze jako wiele kolekcji na kliencie?

Oto pseudo-kod, który pomoże zilustrować moje pytanie:

items kolekcja na serwerze

Załóżmy, że mamitems kolekcja na serwerze z milionami rekordów. Załóżmy również, że:

50 rekordów maenabled właściwość ustawiona natrue, i;100 rekordów maprocessed właściwość ustawiona natrue.

Wszystkie inne są ustawione nafalse.

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
}

Kod serwera

Opublikujmy dwa „widoki” tej samej kolekcji serwerów. Jeden z nich wyśle ​​kursor z 50 rekordami, a drugi wyśle ​​kursor ze 100 rekordami. W tej fikcyjnej bazie danych po stronie serwera znajduje się ponad 458 milionów rekordów, a klient nie musi wiedzieć o nich wszystkich (w rzeczywistości wysłanie ich wszystkich w tym przykładzie zajęłoby prawdopodobnie kilka godzin):

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

Kod klienta

Aby wspierać technikę kompensacji latencji, jesteśmy zmuszeni zadeklarować jedną kolekcjęItems na kliencie. Powinno być jasne, gdzie jest błąd: jak się rozróżniaItems dlaenabled_items iItems dlaprocessed_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());
});

Moje obecne rozwiązanie polega na łataniu małp _publishCursor, aby umożliwić używanie nazwy subskrypcji zamiast nazwy kolekcji. Ale to nie da żadnej rekompensaty za opóźnienie. Każdy zapis musi odbywać się w obie strony na serwerze:

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

Dzięki małpiej łatce będzie działać. Ale przejdź do trybu offline, a zmiany nie pojawią się natychmiast na kliencie - będziemy musieli połączyć się z serwerem, aby zobaczyć zmiany.

Jakie jest właściwe podejście?

EDIT: Właśnie wróciłem do tego wątku i zdaję sobie sprawę, że moje pytanie i odpowiedzi oraz mnóstwo komentarzy niosą ze sobą wiele dezinformacji.

Co sprowadza się do tego, że źle zrozumiałem związek publikowania i subskrybowania. Pomyślałem, że kiedy opublikujesz kursor, wyląduje on na kliencie jako osobna kolekcja z innych opublikowanych kursorów, które pochodzą z tej samej kolekcji serwerów. To po prostu nie działa. Chodzi o to, że zarówno klient, jak i serwer mają te same kolekcje, ale tak jestw kolekcje, które się różnią. Kontrakty typu pub-sub negocjują, które dokumenty trafią do klienta. Odpowiedź Toma jest technicznie poprawna, ale brakowało kilku szczegółów, aby obrócić moje założenia wokół. Odpowiedziałem na podobne pytanie w innym wątku SO, w oparciu o wyjaśnienia Toma, ale pamiętając o moim pierwotnym niezrozumieniu pub-sub Meteora:Strategie publikowania / subskrypcji Meteor dla unikalnych kolekcji po stronie klienta

Mam nadzieję, że to pomoże tym, którzy natkną się na ten wątek i odejdą bardziej zdezorientowani niż cokolwiek innego!