2014 年 5 月 16 日更新
requestInterceptor
v.1.4.12以降、AJAXアダプタでHTTPレベルのタイムアウトとキャンセルを設定できます。ドキュメント「AJAX 呼び出しの制御」を参照してください。
サーバーがデータを永続化したかどうかを知る機会がないため、保存時にこの機能を使用することにはまだ消極的です. もちろん、クライアントがハングしたりクラッシュしたりしても、とにかくわかりません。それはあなた次第です。
元の回答
実際には、Q.jsから既製のソリューションがあります。これは呼び出され、実装の簡単な例とreadme.mdでの使用とともにAPI リファレンスtimeout
に記載されてい ます。
あなたが Save について尋ねたことは知っていますが、あなたの質問はプロミス全般に関連しています。以下は、DocCode サンプルの queryTests.js を基にしたクエリの例です。
var timeoutMs = 10000; // 10 秒のタイムアウト
var em = newEm(); // 新しい EntityManager を作成します
var query = new EntityQuery().from("Customers").using(em);
Q.timeout(query.execute, timeoutMs)
.then(queryFinishedBeforeTimeout)
.fail(queryFailedOrTimedout);
関数 queryFailedOrTimedout(エラー) {
var expect = /timed out/i;
var emsg = error.message;
if (expect.test(emsg)) {
log("メッセージ '{0}' でクエリがタイムアウトしました" + expectTimeoutMsg)
.format(emsg));
//何かをする
} そうしないと {
handleFail(エラー);
}
}
注: このテストを追加したばかりなので、github から取得するか、1.2.5 以降の Breeze リリースを待つ必要があります。
おっと...そうではないかもしれません
queryに対して素晴らしい答えだと思うものを与えました。saveの正解ではないかもしれません。
保存の問題は、サーバーが応答するまで、保存が成功したかどうかがクライアントでわからないことです。途中でどこかで問題が発生する可能性があります。サーバーが保存要求を聞いていない可能性があります。保存中にサーバーに障害が発生した可能性があります。サーバーはデータを保存した可能性がありますが、応答がクライアントに返されませんでした。
の値を変更しallowConcurrentSaves
ても、このバインドから抜け出すことはできません。保存タイムアウトもありません。
実際、保存にタイムアウトを追加することはおそらくだまされています。カスタム タイムアウトの後に保存応答が到着する可能性もあります...その場合、Breeze は EntityManager を更新しようとします...そして、Breeze が成功したか失敗したかはわかりません!
Breeze 保存タイムアウトを追加するとどうなるでしょうか。それは何をすべきですか?Breeze が保存がタイムアウトしたと言い、Breeze がサーバーからの遅れた応答を無視した場合はどうなるでしょうか? 次に、サーバーで保存が成功したと想像してください。クライアントに応答するのに「時間がかかりすぎた」だけです。これで、クライアントの状態が予期せずサーバーと同期されなくなりました。これは良くない。
したがって、この非常に現実的な問題に対する別の解決策が必要だと思います。それは本当にユーザーエクスペリエンスの問題です。保存がまだ進行中であると思われることをユーザーに示してから、独自のタイマーを設定できます。タイマーが切れたときに保存が完了していない場合は、サーバーにクエリを実行して、データが保存されているかどうか、接続があるかどうか、またはこれらの線に沿った何かを確認できます。正直なところ、今より良い方法は思いつきません。
サーバーが成功したことを知る必要があると仮定していることに注意してください。ストアで生成された ID を避け、サーバーから別の指示がない限り、常に保存が成功すると想定する場合、それは完全に異なるパラダイムとプログラミング モデルであり、いつかお話しすることができます ( meteorjsを参照)。
これらすべてのネット:保存タイムアウトがあなたが望むものではないことはかなり確信しています。
ただし、クエリでは引き続き役立ちます:)