Feature request: restrict which cursors are published about meteor-publish-composite HOT 9 OPEN

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

from meteor-publish-composite.

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

from meteor-publish-composite.

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

from meteor-publish-composite.

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

from meteor-publish-composite.

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

from meteor-publish-composite.

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.

from meteor-publish-composite.

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.

from meteor-publish-composite.

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.

from meteor-publish-composite.

any news with internal: true?

from meteor-publish-composite.