問題タブ [meteor-publications]

サーバー上にカスタム パブリケーションがあります (何らかの方法で 2 つのコレクションに参加しています)。

このパブリケーションの結果のセットはまさに私が必要としているものですが、パフォーマンスの問題のため、クライアントに完全に送信することは避けたいと思います.

パフォーマンスを気にしなければ、出版物を購読して、次のようなことをするだけです theCollection.find({"my":"filter"})

したがって、サーバー側のカスタム パブリケーションにフィルターが適用されるように、カスタム パブリケーションのサブセットをパブリッシュする方法を見つけようとしています。

パブリケーションをチェーンまたはフィルタリングする方法はありますか (サーバー側)?

質問については、カスタム パブリケーションが次のようになり、変更できないと想定できます。

私はサブマネージャーを使用していますが、これに対する答えはそのライブラリとは無関係かもしれません。

limit引数が 1 つのサブスクリプションがあります。現在、 を呼び出すとsubs.subscribe 'subname', newLimit、別のサブスクリプションが追加されます。

古いサブスクリプションはまだそこにあります。Meteor が古い制限の低いサブスクリプションを維持するのに時間を費やしたくありません。新しいサブスクリプションを追加する代わりに、古いサブスクリプションの引数を更新したいと考えています。これを行う最善の方法は何ですか？

また、Meteor に最初の 20 個のドキュメントを再送信するという余分な作業を行わせたくないため、たとえば'subname', 20を購読する前に完全に分解したくないことに注意してください。ドキュメント 21 から 40 だけを送信したいのです。'subname', 40

最初のテンプレート用に 10 個のフィールドを持つ 1 つのパブリケーションがあります。

同じパブリケーションの 5 つのフィールドのみが必要な別のテンプレートがあります。読み込まれたテンプレートによっては、ユーザーは両方にアクセスできるため、セキュリティは問題ありません。

質問:

パフォーマンスの観点から、必要な 5 つのフィールドのみを含む別のパブリケーションを作成する必要がありますか?それとも最初のパブリケーションに依存する必要がありますか?

私はそれが次の間のトレードオフになることを期待しています:

1. 送信されたデータの量
2. サーバー側の負荷 (これらの各出版物は を使用しますcursor.observe())
3. 現在サブスクライブしているユーザー数 (mergeBox ロード)

もう 1 つの解決策は、2 つのパブリケーションを作成することです。5 つのフィールドを持つ基本的なものと、その他の 5 つのフィールドを持つ別のものです。最初のテンプレートでは両方にサブスクライブし、2 番目のテンプレートでは最初のテンプレートのみにサブスクライブします。

理論は理解できますが、最適なアプローチを推測することはできません。この種のケースでは、良い慣行があると思います。

すべてが同等である可能性もあり、それは不要なマイクロ最適化になります (そして、それは私の質問に答えるでしょう)。

ありがとう！

パブリッシュされたカーソル (カーソルが指すデータではなく、カーソル全体) を変更すると、Meteor はremoved新しいカーソルに表示されないすべてのドキュメントについてクライアントにメッセージを送信することに気付きました。より技術的な用語で私が意味すること：

変更すると、クライアント側のMiniMongosomeReactiveVarに送信されたすべてのドキュメントmyCollectionが削除されます (新しいカーソルの一部でない場合)。場合によっては、これが必要になることもありますが、私の質問は単純です: これを防ぐことはできますか? どのように？

Meteor には次のようなコレクションがあります。

記事のコレクションには次のスキーマがあります

タグは、本質的に索引付けされた検索用語です。

各記事には、「プライベート」、「グループ」、または「パブリック」に設定された権限があります。

現在、次のようなタグを公開しています。

次に、クライアントで記事のリストをフィルター処理し、公開されている記事、または現在のユーザーによって作成された非公開の記事のみを表示します。

ただし、理想的には、セキュリティ上の理由から、クライアントが非公開記事の記事 ID にアクセスできないように、公開機能自体の中でサーバー側でフィルタリングを行いたいと考えています。クライアントが適切な権限を持っていない限り、実際の記事オブジェクトにアクセスできないようにしていますが、さらに一歩進んで、結果から ID を完全に削除したいと考えています。

だから私が探しているのは、基本的に次の疑似コードを可能にするクエリです:

私は当初、上記とまったく同じ関数を使用してこれを行うことを考えていました (基本的に、すべてのレコードを取得してから、各レコードを調べて手動で配列をプルーニングし、更新されたレコードのセットを返します)。また、基になるデータが変更された場合、レコード セットは更新されません。

ジョブを実行する単一の find() クエリがない場合、関数を使用して追加のパスを実行し、それでもリアクティブ データ セットを返す方法があれば、そのソリューションでも問題ありません。

いずれにせよ、これは非正規化されたコレクションなので (タグも記事ドキュメント内にあります)、さらに非正規化して、記事 ID だけでなく ownerId と許可を含めることもできると思います。しかし、個々の配列要素をテストする方法がまだわかりません。また、可能であれば、必要な非正規化の量を最小限に抑えたいと考えています...