問題タブ [expando]

このQ＆A MongoDB Normクエリのネストされたオブジェクトを見ましたが、強く型付けされたオブジェクトにのみ適用されるようです。

Expandoオブジェクト（https://github.com/atheken/NoRM/wiki/expando）のネストされたフィールドを検索または更新する方法はありますか？基本的に、開発者がドキュメントオブジェクトをサーバーに保存し、Flashクライアントにサービスを提供できるようにするシンプルなJSONCMSツールがあります。開発者がJSONオブジェクトを作成して保存し、ネストされたクエリを作成し、これらのオブジェクトを更新できるシンプルなサービスを提供する必要があります。

データ構造がわからないので、MongoDBを使うのに最適な場所だと思いました。残念ながら、.Netは強く型付けされたデータ構造に適しているようです。

何か案は？ありがとうございました！

エキスパンドのクラスを動的に設定することは可能ですか??

設定した

する方法はありますか

となることによって

実際に格納されている値が表示されます

すべてを出力するために、Expando-Modelの動的プロパティを反復処理しようとしています。次のような独自のメソッドを作成する以外に、これを行う方法はありますか？

そして、テンプレートで-'プラットフォーム'オブジェクトが渡されます：

これは機能しますが、私はただできないことに驚いています：

独自のメソッド呼び出しがなくても...「。items」以外のものを使用する必要がありますか？

ASP.NET ページがあり、jQuery セレクターを使用して、特定のテキスト ボックス (テキスト入力) に関連付けられている検証コントロールをすばやく一致させようとしています。検証コントロールはスパンとしてレンダリングされ、「controltovalidate」プロパティは expando プロパティとしてレンダリングされます。テスト例を次に示します。

次のようにレンダリングします。

問題: ml_test() 関数は Internet Explorer 7 では (予想どおり) 1 を示しますが、Firefox 3.6.8 では 0 を示します。コントロールを追加しようとしましたが、Firefox では一貫して機能しません。

このようなセレクターでのアンパサンドの使用を示すこの投稿を発見しました[@expando=value]が、この構文を試すと、jQuery 1.4.2 でエラーがスローされます。

expando 属性を選択するクロスブラウザの方法はありますか? もしそうなら、適切な構文は何ですか?

xml 列を含む SQL Server データベースがあります。その xml 列をドメイン エンティティ内の expando オブジェクトにマップする必要があります。私はNHibernateを使用しています。これに対応するためにNHibernateを拡張するにはどうすればよいですか? 私は、xml データを取得および設定するために実装をオーバーライドする必要があると想定しています (NHibernate は初めてです) が、NHibernate でそれを行う方法がわかりません。

Google App Engine Expando Classのアプリケーションは何ですか? また、それに関連する優れた実践とは何ですか?

ウィジェットと呼ばれるdbexpandoクラスがあります。

json文字列を渡して、それをdictに変換してから、データストアに追加しています。

私の質問は、動的フィールドを作成するためにdictをループする方法です。

これにより、dictのk値とは反対に、フィールド名として「k」がレンダリングされます。

GoogleコンタクトからのデータをAppEngineのデータストアと同期します...これはPythonで行っており、データストアは後でJavaGAEインスタンスによって読み取られます。

Expandoを使用するのは自然なことでしたが、Javaインスタンスが正しく読み取ることができるかどうかはわかりません。答えが「いいえ、Javaはそれを読みません」の場合、最適な解決策は何でしょうか？

非常によくある設計上の問題があります。Google App Engine のレコードの履歴ログ (監査証跡) を実装する必要があります。履歴ログは構造化する必要があります。つまり、すべての変更を自由形式のテキストに結合して文字列フィールドに保存することはできません。

履歴モデルについて次のオプションを検討しましたが、オプション #1 のパフォーマンスの問題に気付いた後、オプション #3 を実装することにしました。しかし、このソリューションが効率的でスケーラブルかどうかについてはまだ疑問があります。たとえば、オプション #3 で動的プロパティの数が増えると、パフォーマンスが大幅に低下するリスクはありますか?

各オプションの長所と短所について詳しい知識はありますか? または、Google App Engine DB の特性に適用できる他の監査証跡の設計パターンを提案できますか?

1. 従来の SQL の「マスター詳細」関係を使用する
   • 長所
     • SQL のバックグラウンドを持つデータベース開発者にとって理解しやすい
     • clean: 履歴レコードとそのプロパティの直接定義
     • 検索性能: 履歴から簡単に検索 (インデックスを使用できます)
     • トラブルシューティング: 管理ツール (_ah/admin) による簡単なアクセス
   • 短所
     • 多くの場合、GAE DB でこのように 1 対多の関係を実装することは推奨されません。
     • 読み取りパフォーマンス: 長い監査証跡を表示するための過剰な数のレコード読み取り操作 (たとえば、大きなレコード リストの詳細ペイン)。
2. 履歴を BLOB フィールドに保存する (ピクルされた python 構造)
   • 長所
     • 実装が簡単で柔軟
     • 読み取りパフォーマンス: 非常に効率的
   • 短所
     • クエリのパフォーマンス: インデックスを使用して検索できません
     • トラブルシューティング: 管理者データベース ビューア (_ah/admin) でデータを検査できない
     • 不潔: SQL 開発者にとって理解/受け入れが容易ではありません (彼らはこれを醜いと考えています)。
3. Expando の動的プロパティに履歴を保存します。たとえば、フィールドごとにフィールドfieldNameを作成しhistory_fieldName_nます (n=<0..N> は履歴レコードの数です)。
   • 長所：
     • シンプル：実装と理解が簡単
     • トラブルシューティング: 管理インターフェイスからすべての履歴プロパティを読み取ることができます
     • 読み取りパフォーマンス: レコードを取得するための 1 回の読み取り操作
   • 短所：
     • 検索パフォーマンス: 履歴レコードを単純に検索することはできません (名前が異なります)
     • きれいすぎない: プロパティの数は一見すると混乱する可能性があります
4. メイン レコードのリスト フィールドのセットに履歴を保存します。例えば。リストフィールド をfieldName作成するfieldName_history
   • 長所：
     • clean: 履歴プロパティの直接定義
     • シンプル: SQL 開発者にとって理解しやすい
     • 読み取りパフォーマンス: レコードを取得するための 1 回の読み取り操作
   • 短所：
     • 検索パフォーマンス: 常に何らかの値を持つレコードのみをインデックスを使用して検索でき、特定の時間に値の組み合わせを持つレコードを検索することはできません。
     • トラブルシューティング: admin db viewer でリストを検査するのが難しい

上記のコードのように、test.Bは「test」のメンバーではありません。しかし、どうすれば「B」が呼び出していることを知ることができます。私が見つけた唯一の方法はex.Messageを調べることですが、それは適切な方法ではありません。