Databases
StackOverflow2013
Postsdbo
POPublishing/subscribing multiple subsets of the same server collection
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POPublishing/subscribing multiple subsets of the same server collection
    primarykey
    data
    text
    <p><strong>EDIT: this question, some of the answers, and some of the comments, contain a lot of misinformation. See <a href="https://stackoverflow.com/a/21853298/1269037">how Meteor collections, publications and subscriptions work</a> for an accurate understanding of publishing and subscribing to multiple subsets of the same server collection.</strong></p> <hr> <p>How does one go about publishing different subsets (or "views") of a single collection on the server as multiple collections on the client?</p> <p>Here is some pseudo-code to help illustrate my question:</p> <h2><code>items</code> collection on the server</h2> <p>Assume that I have an <code>items</code> collection on the server with millions of records. Let's also assume that:</p> <ol> <li>50 records have the <code>enabled</code> property set to <code>true</code>, and;</li> <li>100 records have the <code>processed</code> property set to <code>true</code>.</li> </ol> <p>All others are set to <code>false</code>.</p> <pre><code>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 } </code></pre> <h2>Server code</h2> <p>Let's publish two "views" of the same server collection. One will send down a cursor with 50 records, and the other will send down a cursor with 100 records. There are over 458 million records in this fictitious server-side database, and the client does not need to know about all of those (in fact, sending them all down would probably take several hours in this example):</p> <pre><code>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}); }); </code></pre> <h2>Client code</h2> <p>In order to support the latency compensation technique, we are forced to declare a single collection <code>Items</code> on the client. It should become apparent where the flaw is: how does one differentiate between <code>Items</code> for <code>enabled_items</code> and <code>Items</code> for <code>processed_items</code>?</p> <pre><code>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()); }); </code></pre> <p>My current solution involves monkey-patching _publishCursor to allow the subscription name to be used instead of the collection name. But that won't do any latency compensation. Every write has to round-trip to the server:</p> <pre><code>// On the client: var EnabledItems = new Meteor.Collection("enabled_items"); var ProcessedItems = new Meteor.Collection("processed_items"); </code></pre> <p>With the monkey-patch in place, this will work. But go into Offline mode and changes won't appear on the client right away -- we'll need to be connected to the server to see changes.</p> <p>What's the correct approach?</p> <hr> <h3>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.</h3> <p>What it comes down to is that I misunderstood the publish-subscribe relationship. I thought that when you published a cursor, it would land on the client as a separate collection from other published cursors that originated from the same server collection. This is simply not how it works. The idea is that both the client and server have the same collections, but it's what is <em>in</em> the collections that differs. The pub-sub contracts negotiate which documents end up on the client. Tom's answer is technically correct, but was missing a few details to turn my assumptions around. I answered a similar question to mine in another SO thread based on Tom's explanation, but keeping in mind my original misunderstanding of Meteor's pub-sub: <a href="https://stackoverflow.com/questions/12223866/meteor-publish-subscribe-strategies-for-unique-client-side-collections/13076752#13076752">Meteor publish/subscribe strategies for unique client-side collections</a></p> <p>Hope this helps those who run across this thread and come away more confused than anything!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USmatb33
    plurals
    1. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POPublishing/subscribing multiple subsets of the same server collection
      1. USjeffthink
      1. VTFavorite
    2. VO
      singulars
      1. POPublishing/subscribing multiple subsets of the same server collection
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POPublishing/subscribing multiple subsets of the same server collection
      1. USvixh
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload