Feature request: restrict which cursors are published

[Diggsey]

At the moment, everything returned by a top-level "find" is automatically published to the client, but I only want the children to be published.

Similarly, sometimes you only want certain fields to be published, but you need all the fields to run the child query. For example, I have a field user.secret which I use as part of a child query, but I don't want to publish that field to the client.

The first feature can be implemented by an option "internal: true" or similar, the second by adding a field specifier to the options, eg. "fields: { secret: false }"

[ghost]

Is there currently a way to restrict certain fields from being returned from a top-level "find" even if you don't need them to run the child query? Queries such as the following don't seem to work in any context, which makes security management more difficult: db.inventory.find( { type: 'food' }, { item: 1, qty: 1 } )

[urossmolnik]

Yes there is. Meteor syntax is db.inventory.find( { type: 'food' }, { fields: { item: 1, qty: 1 } } ).
Documentation

[ghost]

Looks like I need to reread the docs. Thank you.

[reywood]

This may be somewhat related to the discussion in #28.

[Diggsey]

@reywood What are your thoughts on my PR #43 ?

[reywood]

It relies on the private function _compileProjection which doesn't seem like a great idea. The Meteor folks could refactor or remove that function at any time. It also completely removes the observeChanges handler which is a major blow to performance in the default use case. Given these issues, I think PR #43 is a non-starter.

[Diggsey]

It relies on the private function _compileProjection which doesn't seem like a great idea.

True - it would be possible to instead simply duplicate that function here, it's fairly simple.

It also completely removes the observeChanges handler which is a major blow to performance in the default use case.

I don't understand this, if anything removing the call to observeChanges will improve performance. It's better to have one observation running rather than two, and internally observeChanges is implemented in terms of observe anyway.

[reywood]

My mistake. I missed that you moved that functionality into the other observe handler. In poking around, it looks like the Meteor folks are moving the diff logic into a separate package called diff-sequence. I was unable to add this package to a new meteor project. Perhaps it's still under development. Probably worth waiting until they've sorted that out, or, as you said, copy this new implementation until they do. I do think this is a good idea.

I'm leaning towards a transform option rather than a fields option. The transform function would be used before sending the doc to the client, but the untransformed doc would be dispatched to child pubs. I think it gives the same functionality but with more flexibility. Your idea to do the diffing in the observe change handler would address the concerns I voiced in #28.

[sunstorymvp]

any news with internal: true?