title: Publishing/subscribing multiple subsets of the same server collection
body: <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>