問題タブ [object-graph]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
oop - オブジェクトグラフとクラス図の違いは何ですか?
「クラス図」と「オブジェクトグラフ」の意味に違いはありますか?
ruby - ruby からの Facebook オブジェクトグラフ https リクエスト
ユーザーの友達を取得するために、Facebook オブジェクト グラフにどのようにリクエストしますか?
URL を入力すると、ブラウザーで機能します (有効な user_id とアクセス トークンに置き換えられます): "https://graph.facebook.com/user_id/friends?access_token=2227470867|2.AQDi3TbqnqrsPa0_.360"
Net::HTTP.get_response(URI.parse('url')) を使用して Ruby コードから試してみると、URI::InvalidURIError エラー メッセージが表示されます。
ios - CoreData の逆関係は、保持されたプロパティとして表す必要がありますか?
2 つのエンティティ (セッションとユーザー) があります。セッション エンティティには、User エンティティへの LoggedInUser 関係があります。また、User エンティティは、Session エンティティとセッション逆の関係にあります。
Xcode は、直接関係と逆関係の両方について、retain 属性を持つプロパティを生成します。オブジェクトグラフの観点からは大丈夫ですか?私の理解では、逆の関係は割り当てプロパティとして表す必要があります。
また、スキーマ エディターでは、どの関係がメインの関係であるかは表示されません (つまり、loggedInUser はその逆としてセッションを持ち、セッションの逆はloggedInUser です)。
多分私は何かを逃していますか?
ありがとう。
c# - シリアル化 - ストリームからのオブジェクト グラフの表示
シリアル化されたオブジェクト グラフのツリー/ビューを作成できる方法があるかどうか、また誰かがポインターを持っているかどうか疑問に思っています。編集目的は、何らかの理由で逆シリアル化の問題が発生した場合に、シリアル化されたデータに関するレポートを実際に表示/生成して、コードをデバッグする前に問題の原因を特定できるようにすることです。さらに、将来的にはこれを拡張して 2 つのストリーム (バージョン 1、バージョン 2) を取得し、2 つのストリームの違いを強調して、コードの変更中に興味深い情報を誤って削除しないようにしたいと考えています。/編集
従来は Soap または XML シリアライゼーションを使用してきましたが、これらは制限が強すぎてニーズが満たされなくなってきており、通常はバイナリ シリアライゼーションが必要なすべてを実行します。これが採用されなかった理由は、シリアル化されたコンテンツを表示してアップグレードの問題などを修正するのが非常に難しいためです。
そのため、シリアル化された情報に関するビューを作成することを検討し始めました。ISerializable コンストラクターからある程度までこれを行うことができます。
シリアル化情報があれば、m_data メンバーを反映して、実際のシリアル化されたコンテンツを確認できます。このアプローチの問題は、
- ツリーのブランチのみが表示されます。ルートからツリー全体を表示したいのですが、この位置からは実際にはできません。
- 情報を調べるのに便利な場所ではありません。ストリームをクラスに渡して、そこで作業を行いたいと思います。
ObjectManager クラスを見てきましたが、これは既存のオブジェクト グラフで動作しますが、データ ストリームから動作できるようにする必要があります。私は、ObjectReader と __BinaryParser を使用する BinaryFormatted を調べ、ObjectManager にフックします (これにより、コンテンツ全体がフラット リストに含まれることになると思います) が、これを複製するか、リフレクションを介してすべてを呼び出します (2これらの 3 つのクラスの内部) はかなりの作業のように思えるので、より良いアプローチがあるかどうか疑問に思っています。
c# - 2 つのオブジェクト間のナビゲーション パスの構築
任意のオブジェクト グラフ (プロパティとコレクションによってリンクされている) に 2 つの .NET オブジェクト (ルートとリーフ) がある場合、パス (WPF プロパティ バインディング パス、または XML XPath のようなもの) を構築するための既存の API または例はありますか?一方から他方に移動しますか?「ソース」(つまり、パスを見つけたいオブジェクト) は、リーフ オブジェクトになります。
インデックス付きの場所もサポートされている必要があります。(例: Foo.Bar[42].Baz["frog"].Quux
)。
これは主にエラー報告を目的としています。オブジェクトが型名だけでなく、オブジェクト モデル内のどこにあるかを示すエラーをオブジェクトに記録させたいと考えています。(同じタイプのオブジェクトが多数の他のオブジェクト タイプに含まれている可能性があり、問題を修正するために必要なユーザー アクションはその場所によって異なるため、これは重要です。)
各オブジェクトにその親への参照を与え、各親に子に到達する方法を再帰的に尋ねることで、トリックを実行する何かを手動でロールすることができます。しかし、それを行う前に、既存の/より良い解決策があるかどうか疑問に思っていました. (そして、誰かが親リンクを更新するのを忘れた場合、または 1 つのオブジェクトが 2 つの異なるパスから到達できる場合、これは脆弱です。これはまれではありますが)。
entity-framework-4 - EF 4 を使用したエンティティ オブジェクトの部分的な更新
アプリケーションの DAL 層と BL 層を実装しています。WCF サービスとしてホストされ、EF 4 が ORM として使用されます。ロールベースのセキュリティレイヤーと、特定のロールによってオブジェクトの一部のみを更新できるビジネスルールがあります。
問題の簡単な例を次に示します。
このような DTO があります。
このエンティティは、同じフィールドを持つ対応する DB テーブルにマップされます。
- MainType の ID フィールドは主キーです。
- DetailsType の MainTypeID は MainType テーブルへの外部キーです。
- DetailsType の SomeIdentityID は、このサンプルにとって重要ではない他のエンティティへの FK です。
- MainTypeID SomeIdentityID は、DetailsType テーブルの複雑な主キーです。
このようなオブジェクト (1 つのメインとリストの詳細) のグラフがあり、更新操作を実行するユーザーの役割を決定しました。私の仕事は:
- 現在のユーザーが医師の役割を持っている場合 - メイン オブジェクトとすべての詳細オブジェクトの医師フィールドを更新し、新しい詳細オブジェクトを挿入します。
- 現在のユーザーに看護師の役割がある場合 - メイン オブジェクトとすべての詳細オブジェクトの看護師フィールドを更新します。
- 現在の日付を更新済みフィールドに保存
- 現在のユーザー ID を LastUpdateBy フィールドに保存する
- Created フィールドや、このロールによって更新されないその他のフィールドは変更しないでください。
たとえば、ロール Doctor を持つユーザーがいる場合、次のようにする必要があります。
- MainObject の DoctorField1、DoctorField2、Updated、LastUpdateBy を更新します。
- すべての詳細オブジェクトで DoctorDetail、Updated、LastUpdateBy を更新する
- 他のフィールドは変更しないでください。
現在、MainObject の完全なグラフを読み取り、必要な変更を加えて DB に保存する実装があります。このソリューションは動作が遅すぎるため、改善する方法を見つける必要があります。現在、RAW SQLでそれを行う方法を明確に知っていますが、他に何も役に立たない場合に備えて、これが私の解決策になります。
必要なフィールドのみを更新し、別のフィールドを無視するように Entity Framework を作成するにはどうすればよいですか。
String フィールドの ApplyOriginalValues メソッドと ApplyCurrentValues メソッドで、いくつかの成功した結果が得られました。アイデアは、両方のオブジェクトのプロパティに架空の値を割り当てることでした。変更の保存中に変更されていないプロパティ。ただし、このトリックは Boolean、Int32、および Decimal 値では機能しません。すべてのオブジェクトに対して単純なアプローチを使用する必要があります。
この問題に関するアイデアや考えをいただければ幸いです。
c# - NHibernate、(QueryOver を使用して) クエリを分離して複雑なオブジェクトを設定する
クエリのバッチ処理をサポートしていないデータベースを使用しているため、このインスタンスでは NHibernate Futures を利用できません。(デカルト積を避けるため) 複数のクエリを使用して複雑なオブジェクト グラフを作成できることはわかっていますが、アプローチをリファクタリングできるかどうかアドバイスが必要です。
ご注意ください > ここは唯一の開発者ですので、アドバイスを求めてください。
以下は、現在のアプローチを示すサンプル コードです。
上記のコードから、FruitBaskets のリストを作成するために 3 つの個別のクエリを使用していることがわかります。このアプローチは機能していますが、ルートオブジェクトから毎回クエリを実行することなく、すべての子を親オブジェクトに結合するより良い方法があると思います。
where条件を親オブジェクトに適用し、そのクエリの結果を使用してすべての子オブジェクトを自動的に取得できるアプローチはありますか? 子供は 3 レベルの深さ、つまり FruitBasket.Yoghurt.Flavour.Owners に進むことができることに注意してください。
アドバイスをいただければ幸いです。
C# .NET 4、NHibernate 3.0
c# - RESTfulサービスでのwebHttpBindingのバインディングと構成?
私は WCF を初めて使用し、サービスが取る構成の迷宮を回避しようとしています。デフォルトよりも大きいテーブルのエクスポートを返すことができる残りのサービスがあります maxReceivedMessageSize
。だから私はこのサービス/エンドポイントの構成をいじろうとしてきましたが、どこにも行きません。以下は、私が取り組んでいることの要点ですが、何が欠けていますか? List を JSON または XML として返すだけで、デフォルトのしきい値を超えて返せるようにする必要があります。
更新 1 その構成をすべて削除し、既存の webHttpEndpoint セクションで簡単なことを試しました。
同じ結果で。 HTTP/1.1 502 Connection reset by peer
reflection - 複雑なオブジェクト グラフ内のすべての指定された型インスタンスをトラバースして検索する
(vb.Net 4.0 を使用) グラフがかなり複雑なオブジェクトがあるとします。オブジェクトには、プロパティ、配列、その他のコレクション、独自のプロパティとコレクションを持つサブクラスなどがあります。オブジェクト グラフ全体を完全に走査し、すべてのインスタンスを見つけたいと考えています。特定のタイプ T の、これらのインスタンスに対して特定の操作を実行します。オブジェクト グラフの完全なトラバーサルを実行する防弾方法はありますか? 振り返りがあっても、これはエラーが発生しやすい難しい作業のようです。
バイナリ シリアライゼーションについて疑問に思っていたのは、それがどんなに複雑であっても、かなり堅牢な方法でオブジェクトを複製しているように見えるからです。シリアル化する代わりに、指定された型 T のすべてのサブオブジェクトへの参照のリストを返すように、その手法を変更する方法はありますか? しかし、それは純粋な憶測に過ぎません。私は実行可能な解決策を受け入れる用意があります。
cocoa - Cocoa – コア データ オブジェクト グラフ
次のオブジェクトの削除を処理するにはどうすればよいですか? デリート ルールはどのように表示されますか?
私のオブジェクトグラフは次のようになります。
ボス
- Boss-Department には多対多の関係があります
- ボスが削除された場合、そのボスに属する部門は削除されません(ただし、このボスとの関係は削除されます)。
デパートメント
- Department-Employee には多対多の関係があります
- 課長は多対多の関係にある
- 部門が削除された場合、その部門に属する従業員は、他の部門との関係がない場合は削除する必要があります
従業員
- Employee-Department には多対多の関係があります
- 従業員が直接削除されることはありません (部門の削除のみ)。ああ幸せな人生!