私は再開したい分割されていない変更フィードを作成しています。 X秒ごとに新しい変更をポーリングします。以下のチェックポイント変数は、最後の応答継続応答を保持します。DocumentDbは分割されていない変更フィードのレジュームを最適化します
private string checkpoint;
private async Task ReadEvents()
{
FeedResponse<dynamic> feedResponse;
do
{
feedResponse = await client.ReadDocumentFeedAsync(commitsLink, new FeedOptions
{
MaxItemCount = this.subscriptionOptions.MaxItemCount,
RequestContinuation = checkpoint
});
if (feedResponse.ResponseContinuation != null)
{
checkpoint = feedResponse.ResponseContinuation;
}
// Code to process docs goes here...
} while (feedResponse.ResponseContinuation != null);
}
注意チェックポイントの周りの「if」ブロックを使用します。これは、これをそのままにしておくとresponseContinuationがnullに設定されるため、リクエストの継続をnullに設定すると、変更フィード内の最初のドキュメントがプルされるため、ポーリングサイクルが再開されるからです。
しかし、各ポーリングループは、単に追加の変更ではなく、以前のドキュメントのセットを再生するという欠点があります。これをさらに最適化するために私ができることはありますか?これは変更フィードAPIの制限ですか?
ありがとう、それは私が言及してきたことでした。私は、パーティション範囲を読み取るのではなく、ReadDocumentFeed操作でこれを行うことができればと考えていました(複数のリーダー間でフィードを読み込む必要はありませんが、パーティション化されたコレクションがあります)。 記事の「インクリメンタルなReadDocumentFeedを実行する」セクションだと思っていますが、.NET SDK操作から読み込んだときには、あなたが言及しているクエリ操作を参照しています。 –
また追加する価値があります - CreateDocumentChangeFeedQueryメソッドがIDocumentClientインターフェイスにない理由は何ですか?私はNuGetパッケージのバージョン1.11.1を使用しています。 DocumentClientクラスを直接使用する必要があります。 –
新しいメソッドを追加すると、IDocumentClientでモックを実装した開発者にコンパイルエラーが発生する可能性があるため、IDocumentClientから削除しました。しかしこれは一般的なリクエストであり、今後のリリースで追加する予定です。 –