idempotencyを維持するためにドキュメントキーとして使用するものは何ですか？

Question

idempotencyを維持するためにドキュメントキーとして使用するものは何ですか？

メッセージをローカルに保存するためにCouchDB（クライアント上のPouchDB）を使用するテキストメッセージングアプリケーションを構築しています。 Twilio（SMSプロバイダ）は各メッセージのIDを生成し、それをCouchDBのドキュメントIDとして使用します。 TwilioのAPIからメッセージをフェッチすることは冪等であり、同じメッセージを2回出すと、データベースに1つのコピーしか保存されません。

// twilio API /messages 
[ 
    {smsid: 123, body: 'foo'}, 
    {smsid: 456, body: 'bar'} 
] 

// transformed into couchdb docs 
[ 
    {id: 123, doc: {_id: 123, body: 'foo'}}, 
    {id: 456, doc: {_id: 456, body: 'bar'}} 
] 

これは twilioからのメッセージを取得する際に行うのは簡単です。しかし、ユーザーがクライアントアプリケーションから送信メッセージを送信すると、まだtwilioに送信されていないため、まだtwilio IDはありません。

伝統的なアプローチでは、自分のサーバー上のあるエンドポイントにメッセージを送り、サーバーがtwilioに送信してからtwilioの応答からsmsidを取得した後にそのレコードをデータベースに追加させます。この問題は、（a）ユーザが「送信」を押してからUIにメッセージが表示されたときに顕著な遅延があり、（b）couchdbの認証システムを利用できないことです。

代わりに、クライアントがランダムIDを生成し、それを（pouchdb w/syncを介して）データベースに挿入するように設定しました。サーバーは、追加された新しいアウトバウンドレコードを監視し、twilioにディスパッチします。

このアプローチはうまく動作しますが、私は再びGET /messages場合、それはもはや冪等ません - 私はそのメッセージのsmsidそのキーなどでCouchDBのドキュメントを持っていないので、それは、送信メッセージ用の追加レコードを作成します（それはdidnのそれがcouchdbに追加されたときにsmsidがあります）。

これ以上の方法がありますか？

Answer 1

あなたの返信ありがとうございます。これは厳しいものでした。 freenodeの中#couchdbから@rnewsonはこの1について考えていくつかの時間を過ごすために親切だったし、素晴らしい働いたソリューション提案：CouchDBの中

• メッセージ文書は、サーバまたはによって生成することができる任意の_idを使用しますクライアント
• クライアントがメッセージを送信すると、任意の_idが生成され、データベースに格納されます。サーバーはこれを観察し、twilioするためにそれを派遣し、私は、サーバーが起動すると、それはからの最新のメッセージをフェッチtwilio_id
• によってインデックスを視野に文書を作成した文書
• へtwilio_idプロパティを追加することで、データベースのドキュメントを更新しますtwilio。重複したレコードをデータベースに追加しないようにするため、各ビューのtwilio idに対して上記のビューを照会します。一致するたびに、一致の_idと_revを使用して更新を実行します。一致するレコードがない場合は、新しい任意の_idを生成して挿入を実行します。

好奇心が強い人にとっては、here's the codeです。

ご回答いただきありがとうございます。

Answer 2

この作業を行うには、各メッセージからrely on other dataする必要があり、Twilioのsmsidは無視してください。

おそらく、ユーザーID、メッセージ本文、およびタイムスタンプのアブストラクトバージョン（たとえば、int(UNIX-TIMESTAMP-IN-SECONDS/100)は、サーバーがメッセージを取得してからTwilioがそれを認識するまでに100秒の遅延を許容します）。