Meteorネットワークから長時間 (数時間) 切断されるフレームワークを使用してアプリケーションを作成することに興味があります。meteor は、ミニ mongodbjs構造の RAM にローカル データを格納していると思います。ユーザーがブラウザーを閉じるか、ページを更新すると、ローカルでの変更はすべて失われます。ローカルの変更がディスク ( localStorage? indexedDB?) に永続化されるとよいでしょう。Meteor が間もなく登場する可能性はありますか?
関連する質問... Meteor はドキュメントの競合をどのように処理しますか? つまり、2 人のユーザーが同じ MongoDB JSON ドキュメントを編集した場合、その競合はどのように解決されるのでしょうか? 楽観的ロック？
競合の解決は「最後のライターが勝つ」です。
具体的には、クライアントでの MongoDB の挿入/更新/削除操作はそれぞれ RPC にマップされます。特定のクライアントからの RPC は、常に順番に再生されます。異なるクライアントからの RPC は、特定の順序保証なしでサーバー上でインターリーブされます。
切断中にクライアントが RPC を発行しようとすると、それらの RPC はクライアントが再接続するまでキューに入れられ、サーバーに対して順番に再生されます。複数のクライアントがオフライン RPC を実行している場合、それらがサーバー上で最終的に実行される順序は、各クライアントがいつ再接続するかに大きく依存します。
MongoDB$incやなどの一部のオフライン ミューテーションで$addToSetは、このモデルはそのままでも十分に機能します。しかし、ミューテーションが他のクライアントからの介入変更と競合する可能性があるため、多くの一般的な修飾子$setは、長い切断ではうまく動作しません。
したがって、「オフライン」アプリを構築することは、ローカル データベースを永続化するだけではありません。また、ある種の競合解決を実装する RPC を定義する必要があります。最終的には、さまざまな解決スキームを実装するターンキー パッケージを用意したいと考えています。