問題タブ [consistency]

ですから、私の目標は数独パズルを解くメソッドを書くことです。メソッドスタブ「publicint [] []solve（int [] []board）」が与えられました。解決策を見つけるために、アークの一貫性とドメイン分割を使用することになっています。

-私が始めた方法は、ボード上のポイント（キー）とその現在のドメイン（指定されていない限り1..9に初期化）のハッシュマップを作成することでした->HashMap<Point, ArrayList<Integer>> curDomains = new HashMap<Point, ArrayList<Integer>>();これが最適なデータ構造であるかどうかはわかりませんが使用する。

-私の質問は、円弧と拘束をどのように表現するかです。アルゴリズムの擬似コードがありますが、Javaで制約/アークを表現する方法がわかりません。C：満たすべき制約のセット（数独ボード上の有効な配置）と、アークA <X、c>（Xはポイント、cは制約）を表すための最良の方法は何ですか。

有益なコメントをよろしくお願いします。

たとえば、次のような C API があるとします。

これらの関数は、再入可能ではないと文書化されています。これを強制する必要がありますか (たとえば、どこかにフラグを設定し、適切なエラー コードを返すことによって)、またはオフの場合は未定義の動作として記述する必要がありますか? 私が見たコードのほとんどは、これを試みていません。それが意識的な決定なのか、それとも単なるプラグマティズム (あるいは怠惰) なのか、私はただ疑問に思っています。本当に堅牢なコードを書きたい場合は、次のようなことを試してください。一方、ドキュメントに従っていない場合は、おそらくすべての賭けをオフにする必要があります。

SDK の保守を担当するチームの一員として、私の経験は時々恐ろしいものでした。確かに私たちのドキュメンテーションは素晴らしいものではありませんが、OEM のサポート リクエストでかなり奇妙なことがいくつか見られました。それらのかなりの数は、別の関数によって呼び出されたコールバックのコンテキストで関数を呼び出すことから生じます。これらのほとんどはサポートされていないと文書化されていますが、それを防ぐためのコードはありません。実際、これのほとんどのインスタンスは機能しているように見えますが、実際に内部状態を台無しにするものもあります。人にドキュメントを読んでもらうよりも、適切な API の使用を強制する方が簡単な場合があるようです。

アプリケーションをAppEngineデータストアからMongoDBバックエンドに移植している最中であり、「ドキュメントの更新」の一貫性について質問があります。1つのドキュメントの更新がすべてアトミックで分離されていることは理解していますが、異なるレプリカセット間で「一貫性がある」ことを保証する方法はありますか？

私たちのアプリケーションでは、多くのユーザーが1回の更新中にいくつかの埋め込みドキュメント（オブジェクト）を挿入することで、1つのドキュメントを同時に更新しようとする可能性があります。これらの更新がすべてのレプリカで論理的に一貫した方法で行われるようにする必要があります。つまり、1人のユーザーがいくつかの埋め込みドキュメントを親ドキュメントに「配置」すると、他のユーザーは、確実に完了するまで、埋め込みドキュメントを親ドキュメントに配置できなくなります。最初のユーザーの更新を読んで受け取りました。

つまり、一貫性とは、2人のユーザーが1つのドキュメントに対してまったく同時に更新を実行しようとした場合に、MongoDBがそれらの更新の一方のみを許可し、もう一方を破棄する（または少なくとも両方が発生するのを防ぎます）。ここでは、標準の「シャーディング」ソリューションを使用できません。これは、単一の更新が単なるインクリメントまたはデクリメント以上のもので構成されているためです。

1つの特定のドキュメントの一貫性を保証する最良の方法は何ですか？

データベースをエクスポートしてから、新しいデータベースにインポートしました。次に、サイズに違いがあることがわかります。これは、エクスポートされていない削除済みエントリのスペース再利用の問題によるものであることがわかりました。

したがって、2 つのデータベースは、アクティブな (削除されていない) エントリに関して同一である必要があります。しかし、どうすればそれを確認できますか？[システム: linux、mysql、phpmyadmin、webminなど]

ご存知のように、cassandra には ReplicationFactor の ConsistencyLevel があります。そして、データの一貫性を維持するためにそれを活用したいだけです. 価格情報を保持することになっているためです。

では、どの戦略が優れているでしょうか？

Write ALL クライアントに応答する前に、N 個のレプリカすべてに書き込みが行われるようにします。応答しないレプリカは操作に失敗します

Read ALL すべてのレプリカを照会し、すべてのレプリカが応答すると、最新のタイムスタンプを持つレコードを返します。応答しないレプリカは操作に失敗します。

確かに write ALL が最も安全なようです。しかし、すべてを読む方が良いかどうかわかりませんか? 賛否両論について何か意見はありますか？あなたがより良いと思うnosqlの他の選択肢はありますか？

Ivy について 2 つの関連する質問があります。

Ivy の「checkconsitency」フラグのドキュメントには次のように記載されていることに注意してください。

「checkconsistency 属性を使用すると、Ivy がモジュール記述子を見つけたときに期待するものと、モジュール記述子に実際に含まれるものとの間の整合性チェックを有効または無効にすることができます。」

1) ここでの「一貫性チェック」とはどういう意味ですか? Ivy が特定のモジュールをアプリオリに「期待」するのはなぜですか?

と

2) checkconsistency は checkmodified とどう違うのですか? これらは何らかの意味で冗長である可能性があるようですが、よくわかりません。

コンテキストについて-私はnexus/mavenリポジトリがどのように設定されているかの内部の専門家ではないので、これらのツタの「チェック」の背後にあるアイデアを理解するのに役立つ重要なコンテキスト情報はおそらく非常に役立ちます.

ヘクターミューテーターを使用して、N シーケンシャル操作で行を更新します。Mutator に追加された順序で変更が行われるという保証はありますか?

最も単純な例は、行を削除してすぐに再作成した場合です。挿入後に削除が発生することはありませんか?

2 つの連続する要求が異なるノードに送信された場合、cassandra クラスターはそれをどのように管理しますか? ノード間に数ミリ秒の差がある可能性は常にあります...

アプリケーション用の単純な更新サーバーを構築中です。更新されるアプリケーションの部分は構成ファイルです。これらのファイルの最新のコピーは更新サーバーに存在し、これらのファイルは、アプリケーションを管理する個人 (「アプリケーション マネージャー」) がいつでも編集できます。ただし、ファイルがアプリケーション マネージャーによって編集されている間に、アプリケーションがこれらのファイルの 1 つをダウンロードできるようにしたくありません。これは明らかに一貫性の問題を引き起こします。これらのファイルが一貫性のない状態でアクセスされるのを防ぐにはどうすればよいですか? または、アプリケーションがファイルが一貫した状態で受信されたかどうかを判断するために使用できるチェックサムをファイルとともに提供することで解決できますか?

編集: .htcaccess を使用したアクセス制限に関するこの投稿を見て、役に立つと思います。しかし、私は、アプリケーション マネージャーができるだけ何も考えないようにしたいと考えています。接続を再許可することを忘れると、問題が発生する可能性があります。そうは言っても、ある時点で何らかの作業を行う必要があります。多分これは私が行くべき道ですか？

私が重要だと思うことの1つは、WindowsPhoneのすべてのページとすべてのアプリの一貫したルックアンドフィールをユーザーに提供することです。ネイティブアプリと同じようにきれいなページめくりを行う方法を理解しました。次に、すべてのリストボックスアイテムをネイティブアプリと同じように表示する方法を理解しようとしています。

たとえば、設定アプリでアイテムをクリックすると、指を置いたままアイテムのテキストが少し縮小し、ボタンを離すとテキストが通常のサイズに戻り、ページナビゲーションが開始されます。 。

ページナビゲーションができます。しかし、ナビゲーションボタンは、ちょっと似ているだけでなく、まったく同じにしたいのです。実際のところ、ユーザーがMicrosoftが作成したと思われるように、アプリ全体を他のOSに均一に準拠させたいと考えています。Microsoftが使用してアクセスできる標準ライブラリ、一連のコントロール、またはフレームワークはありますか？Microsoft UIデザインを模倣する方法を紹介するブログやその他のリソースはありますか？

ユーザーインタラクションまたはOSイベントによってアクティビティの存続期間中に変更される可能性のある同種のアイテムのリストがあるとします。には、の数を示すActivityが含まれています。FragmentPagerListFragment

これらのフラグメントは前述のデータを共有しますが、さまざまな方法で表示します。たとえば、並べ替え順序が異なる場合や、データのサブセットのみが表示される場合などです。現在、各フラグメントは、データのそれぞれの部分をそれぞれの順序で含む個別のリストを保持しています。

データが変更されると、基本的にすべてのフラグメントを更新する必要があります。これは、一部のフラグメントからアイテムを再利用または追加/削除することを意味します。さまざまなフラグメントのデータの一貫性を保つためのベストプラクティスは何ですか？

現在、ある種のオブザーバーオブジェクトがあります。これは、何かが変更されたときに通知され、その後、接続されたフラグメントに通知されます。しかし、いくつかの問題があります。

• アプリが起動したばかりのとき、一部のフラグメントはFragmentPagerによって作成されていないため、通知することはできません。
• フラグメントをスワイプすると、一部が一時停止します。この状態では、リストを更新できません。この場合、オブザーバーから切断する必要がありますか？これはにつながります：
• 変更が発生すると、フラグメントが切断されている間、基本的にそれを見逃します。
• 等々...