問題タブ [one-to-one]

satchmoアプリケーションの管理者をまとめています。SatchmoはOneToOneリレーションを使用して基本Productモデルを拡張しているので、すべてを1ページで編集したいと思います。

インラインとしてOneToOneリレーションを持つことは可能ですか？そうでない場合、最終的にOneToOneリレーションに保存される管理者の特定のページにいくつかのフィールドを追加するための最良の方法は何ですか？

例えば：

管理者のためにこれを試しましたが、機能せず、外部キーを期待しているようです。

これはこのエラーをスローします：<class 'satchmo.product.models.Product'> has no ForeignKey to <class 'my_app.models.MyProduct'>

これを行う唯一の方法はカスタムフォームですか？

編集：フィールドを直接追加するために次のコードを試しました...これも機能しません：

次の関係をモデル化したいと思います。

これはすべて、メインクラスの継承を形成します...基本フォームと、いくつかの特定のフォーム..TerminationForm、別のフォーム...など...

そして、各子フォームから他のいくつかのフォーム セクションをぶら下げるつもりでした。これらの子フォームを [OneToOne] としてモデル化しました

つまり、TerminationForm が上記の FormOne に類似している場合..その下に「Staffing」があります..これがリンクです..およびその相互リンクです (注...いくつかの Staffing プロパティを抽象ベースに引き上げました。退職スタッフと休暇スタッフ)

AR がスキーマを作成すると、主キーを制約する関係を介して、TerminationForm を MasterForm に適切に関連付けます...

ただし、 TerminationStaffing テーブルに MasterFormId が含まれていても、作成されたリレーションは表示されません。これについて心配する必要がありますか？後で追加できるかもしれませんが、驚きました。

TerminationStaffing で [BelongsTo] を使用することを考えましたが、TerminationForm でどのような関係になりますか (関係は 1 対 1 です。1 対多ではありません)。

私はベースから離れていますか？

3 つの Java クラス (Person から Heart、および Person から Liver) のオブジェクト間の単方向の 1 対 1 の関係が必要です。オブジェクトが同じ PK を共有するようにします。つまり、すべての人が対応する心臓と肝臓を持っています。それぞれにたくさんのフィールドがあるため、3 つのテーブルを 1 つにマージしたくありません。これが私のコードです（主にこの質問に対する受け入れられた回答に基づいています）：

セッションをセットアップし、次のことを行います。

次に、人物オブジェクトを臓器にリンクして保存すると、エラーが発生します (注: Person と Heart などの 2 つのクラスを使用したときと同じ動作が得られました)。

org.hibernate.id.IdentifierGenerationException: null の 1 対 1 のプロパティから ID を割り当てようとしました: person

ただし、関係を両方の方法で設定すると機能します。

しかし、確かにこれは一方向の関係には必要ないのでしょうか?
乾杯

ps。奇妙なことに、Person と Heart などの 2 つのクラスを使用し、リンクを別の方法で設定すると、機能する (両方のオブジェクトが DB に保存される) ことに気付きます。

なぜこれが機能するのかわかりません (Person は親オブジェクトであり、独自の PK を自動生成し、他のオブジェクトがそれを使用するため、セットアップする必要があるのはそれだけです) が、とにかく私には理解できませんこの作業方法を私の3クラスの状況に適用する方法...

Linq2SQL で 1 対 0 または 1 の関係を作成することは可能ですか?

私の理解では、1 対 1 の関係を作成するには、各テーブルの PK で FK 関係を作成します。

しかし、PK を null 可能にすることはできないため、1 対 0 または 1 の関係を機能させる方法がわかりません。

私はデザイナーを使用してモデルを自動的に作成しています。そのため、カスタム ORM コードではなく、SQL テーブルを設定して関係を誘導する方法を知りたいと思います。

これは私が以前持っていたものです（しかし、明らかにこの順序でそれを行うことはできないことに気づきました：

例から私がやりたいことがわかると思います。AccountAdminの属性を共有するMasterAccountAdminが必要です。目的は、MasterAccountAdminではなくAccountAdminを削除できるようにすることです。AccountAdminに「master=models.BooleanField（）」という属性を付けたくありませんでした。

MasterAdminは作成前にAccountAdminを参照しているため、この例は明らかに機能しませんが、私が達成しようとしていることを示したかったのです。私はこれをすべて間違っていると思っていますか？

私のアプリには、それぞれが 1 つの課金プロファイルを持つクライアントがあります。

「 BillingProfile 」という別のモデルを参照する「 billing_profile 」という属性を持つ「 Client 」モデルを持つアプリを想定しています。「クライアント」に戻る外部キーを使用して「 BillingProfile 」を定義するのではなく(つまり、「 client = models.ForeignKey(Client)」)、クライアントごとに単純に使用できる請求プロファイルが 1 つしかないため、と考えていました。代わりに 1 対 1 のフィールド。これは理にかなっているように見えますか、それとも後ろ向きに見えますか (その場合、クライアントを確立する前に BillingProfile を作成する必要があります)。それを理解する私のパラダイムに対してこれを行う良い方法はありますか?

それぞれが入れ子になっている 3 つのモデルがあるとします。最上位オブジェクトを作成し、他の子オブジェクトを build_* にすると、元のインスタンスの save() 前後のリレーションシップを通じてすべての子オブジェクトを取得できます。ただし、 find(:id) の後に第 2 レベルのネストされたオブジェクトを取得しようとすると、元の親は失敗します。ただし、第 1 レベルのネストされたオブジェクトは取得できます。これは通常コントローラーで発生しますが、以下のコンソール出力で説明します。

私は何を見落としていますか？

前もって感謝します！
~jpv

以下のすべてのボイラープレートのもの：

適切な外部キーは、「belongs_to」クラスのそれぞれにあります。

この例のために簡略化した次の db テーブルがあります。

Web ページID、URLIdentifier

WebpageMetaData Webpage_id キーワード

Webpage_id は、テーブルの主キーであり、Web ページ テーブルへの外部キーです。

次に、Fluent NHibernate とその自動マッピング機能を使用して、これらを次の POCO クラスにマップします。

}

}

これらのエンティティを 1 対 1 でマッピングしたいので、次のように自動マッピングをオーバーライドします。

これらのマッピングとカスケード ルールをテストしたところ、選択、挿入、更新に使用できます。ただし、WebpageMetaData の削除を実行すると、例外が発生します。

「削除されたオブジェクトはカスケードによって再保存されます (関連付けから削除されたオブジェクトを削除します)[WebpageMetaData#524]」

例外を停止する唯一の方法は、保存する前に次の操作を行うことです。

したがって、親から自分自身への null 参照を設定する必要がありますか??! これは間違っているようですか？マッピングが間違っていますか？

ありがとう。

更新 1: FLuent が生成している NH マッピングを参照してください。ハードコアな NHibernator の助けになる場合があります:)

(非常に) 長い間、Fluent NHibernate を使用して1 対 1 のマッピングを正しく実装する方法の例を探していました。

私が見つけたほとんどのリソースは次のように述べています。

私はあなたが多対一を意味していると思います

しかし、1 対 1 の関係を正しく実装する方法について実際に例を挙げている人は誰もいません。

Fluent NHibernate を使用した 1 対 1 のマッピングの例を教えてください。

注: 「あなたのモデルは何ですか。実際にはHasManyが必要かもしれません」という人には興味がありません。いいえ、1 対 1 の例が必要です。

より正確には、構文を知っています。自分で検索して出てきたのはこれだけです。私が探しているのは、((非常に) 単純な) データベースのセットアップと、関係に参加するすべてのエンティティのマッピング全体を含む、より完全な例です。これは、スタック オーバーフローに妥当なサイズになると思います。