<kentonv>
a meteor subscription causes some subset of the Mongo database to be replicated to the client
<kentonv>
when you later query that data (on the client side), you query the collections that have been populated by the subscription, but you don't query the subscription
<isd>
So the first argument to subscribe is the name of a client-side collection to populate?
<isd>
But, there are places where we're doing subscribe("table we never appear to query"). Is that just dead code that we should remove/update?
<kentonv>
the first argument to Meteor.subscribe() is the name of a corresponding Meteor.publish()
<kentonv>
this may or may not have anything to do with a collection name
<kentonv>
in fact a single subscription can populate multiple collections
<isd>
> When you subscribe to a record set, it tells the server to send records to the client. The client stores these records in local Minimongo collections, with the same name as the collection argument used in the publish handler’s added, changed, and removed callbacks. Meteor will queue incoming records until you declare the Mongo.Collection on the client with the matching collection name.
<isd>
So if a publish just returns a mongo cursor (perhaps after filtering), you would query the underlying collection name?
<JacobWeisz[m]>
I really should try to learn Meteor. I used Giftr for the first time this year. Love it, but simple stuff it doesn't do annoys me.
<isd>
You should definitely do that, and you should hack on Sandstorm core too.
<JacobWeisz[m]>
Probably a lot easier to hack on Giftr than Sandstorm core. ;)
<JacobWeisz[m]>
It would be a good small step for anyone interested in Sandstorm shell dev.
nicoo has quit [Quit: WeeChat 1.7.1]
nicoo has joined #sandstorm
xet7 has quit [Ping timeout: 256 seconds]
dustyweb has quit [Ping timeout: 260 seconds]
blowfist has quit [Read error: Connection reset by peer]