問題タブ [neventstore]

私はjoliver/EventStoreライブラリを使用しており、ストリームからイベントを読み取らない方法を見つけようとしています。

その理由は、そこから 10,000 件のメッセージをすべてロードせずに、特定のストリームのストアにいくつかのイベントを書き込みたいだけだからです。

joliver eventstore をダウンロードして、Windows Service Bus 1.0複数の Bounded Context プロセスにまたがって分離されたアプリケーション用にサービス バスを接続しようとしています。

他の境界付けられたコンテキストのイベントが作成されている間に境界付けられたコンテキストがオフラインになっている場合 (または展開された新しいコンテキストである場合もあります)、次の一連のイベントを確認できます。

1. ContextA、ContextB、および ContextC の例では、すべて Service Bus 1.0 を使用して接続されており、各コンテキストは独自のイベント ストアを使用しており、すべて同じバス メッセージング バックプレーンを共有しています。
2. ContextC がオフラインになります。
3. ContextC が復旧したら、オンラインに戻ったばかりのコンテキストに再送信する必要があるイベントについて、他の境界付けられたコンテキストに通知する必要があります。これらのイベントは、各イベント ストアから再生されます。

私の質問は次のとおりです。

1. 上記のシナリオはすべてのイベント ソーシング ライブラリに適用されます。この上に使用できるインフラストラクチャ コードはありますか?それとも独自に作成する必要がありますか?
2. Windows Service Bus 1.0 では、イベント ストアのシーケンス番号を Service Bus のシーケンス番号と結合するにはどうすればよいですか?
3. 既に受信したイベントを安全な方法で検出して処理するためのベスト プラクティスは何ですか (メッセージ ハンドラーの失敗から保護します)。

誰かが以前にこれに遭遇したことがあるかどうか疑問に思います：

コマンドを処理し、ハンドラーでイベントをイベントストア（joliver）に保存します。
ディスパッチ直後に、同じコマンドのハンドラーが再度処理されます。
コマンドのGUIDが同じであるため、同じコマンドを知っています。

5回試行した後、nservicebusは、最大再試行のためにコマンドが失敗したと言います。
したがって、明らかにコマンドは失敗しましたが、何が失敗したのかはわかりません。ディスパッチャの内容をtrycatchに入れましたが、エラーはありません。コードがディスパッチャを終了した後、イベントハンドラは、何かエラーが発生したかのように常に起動します。

コードをトレースすると、イベントがデータベースに保存され（行が表示されます）、ディスパッチャーが実行され、[ディスパッチ]列がtrueに設定されます。その後、ハンドラーがコマンドを再度処理し、プロセスが繰り返され、別の行が挿入されます。 commitsテーブルに追加します。

何が失敗しているのでしょうか？イベントストアのどこかに成功フラグを設定していませんか？イベントストアをnServicebusから切り離すと、両方とも期待どおりに実行され、再試行や失敗は発生しません。

ディスパッチャ：

Wireup.Init（）

私はEventStoreについて多くのことを見てきましたが、すべての記事はCQRSについての話と結びついています。

EventStoresを使用して境界付きコンテキストを統合しますが、集約の読み取り/書き込みには従来のORMを使用して、コマンド/クエリと個別の読み取りモデルを使用しないようにします。この場合、複雑さが増します。

両方の概念について一緒に話すことが非常に人気があるので、それらは一緒に暮らすことを意図していると信じられます-アグリゲート/ CQRS /読み取りモデルにもEventStoreを実装する場合と比較して、CQRSなしでEventStore「ライト」を実行することの落とし穴はありますか？

私は最初の EventStore テスト アプリを作成しています。ストリームからオブジェクトを再水和しています。numberSold は正しく取得されますが、タイトルが null で、理由がわかりません。ストリームから取得したコマンドには、タイトルは null に設定されていますが、問題なく書かれているはずです。

新鮮な目で私が間違っていることを見ることができますか?

ブッククラス

ブックリポジトリ

コマンド

私が知る限り、SQL データベースの Commits テーブルの Payload 列に JSON を表示する必要がありますが、長い 16 進数の文字列があります。

私のワイヤーアップ コードは、次の編集を加えたサンプルのとおりです。

JSON を取得してデバッグを容易にする方法はありますか?

@Jonathan Oliver の EventStore の SQL 永続性がCommitSequence、重複コミットを検出する基準の 1 つとして使用されるのはなぜですか? なぜ十分ではないStreamIdのですか？CommitId

以下の SQL を参照してください。

この SQL ステートメントは からのものSqlPersistenceEngine.DetectDuplicate()です。DuplicateCommitExceptionをスローするか、単に をスローするかを決定するために使用されConcurrencyExceptionます。

Jonathan Oliver の EventStore の RDBMS スキーマに次のインデックスの項目が含まれるのはなぜですか?