[Seasar-user:15622] Re: 【DBFlute】主キーではない項目の外部キーについて

kubo [E-MAIL ADDRESS DELETED]
2008年 9月 2日 (火) 19:00:07 JST


久保(jflute)です。

>> A. PK無しでユニーク制約キーだけあって、それをFKしてる
>> B. PKは別に存在している
> 「B. PKは別に存在している」です。

了解です。ありがとうございます。
もし「A」だったら、
ユニークキーをadditionalPrimaryKeyとして
DBFluteの中だけでPKとして取り扱うようにすれば
回避できるかなと思ったのですが、「B」でそれを
やるとPK定義が重複してへんな動きになりそうですね。

今、実現可能性を検討しているのですが、
申し訳ありませんが、少なくともすぐに
どうにかなるようなものではなさそうです。
引き続き検討はしていきますが、
一つ思いついた回避策を提示しておきます。
(実際に試してはいないです)

additionalForeignKeyでFK先がユニーク制約だと
loadReferrerが生成されない件ですが、
ExtendedのBehaviorの直接自分で実装してしまうやり方が考えられます。
他のloadXxxList()メソッドを参考に作成すればいけるかもしれません。
ちょっと実装を把握するのが大変ですが、ひとまず回避策として。
(additionalForeignKey + 独自でload実装)

2008/9/2 土居俊彦 <[E-MAIL ADDRESS DELETED]>:
> 土居です。
>
> 08/09/02 に kubo<[E-MAIL ADDRESS DELETED]> さんは書きました:
>> 久保(jflute)です。
>> もう一つ確認させて下さい。
>> FK先のテーブル(ユニーク制約キーのある方)は:
>>
>> A. PK無しでユニーク制約キーだけあって、それをFKしてる
>> B. PKは別に存在している
> 「B. PKは別に存在している」です。
>
>
> --
> 土居俊彦(DOI Toshihiko)
> http://www.t-doi.org/diary/
> [E-MAIL ADDRESS DELETED]
> [E-MAIL ADDRESS DELETED]
> [E-MAIL ADDRESS DELETED]
> [E-MAIL ADDRESS DELETED]
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user
>


Seasar-user メーリングリストの案内