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

[kubo]

久保(jflute)です。

> 今のところ、DBFluteが出力するXMLを手で修正して外部キーを設定することで、とりあえず回避できています。
>
> ただ、replace-schema実行時に毎回修正が必要となるので、自分で実装する方法も検討してみたいと思います。

了解しました。
よろしくお願いします。


参考までに確認させて下さい。
> XMLを手で修正して外部キーを設定することで
とありますが、
こちらadditionalForeignKeyMapで設定した場合と挙動は同じかと
思うのですが、XMLを手で修正だとloadReferrer()が生成されましたか？
(結局FK先カラムがPKでないので同じ挙動ではないかと)

#
# もしくは、loadReferrer()が生成されても実行すると正常に動作しないかも...
#


【Tips】
独自のloadReferrerをExtendedのBehaviorに実装する方法ですが、
InternalLoadReferrerCallbackを実装しているところで、
GenericのPK_TYPEとcallbackBase_getPrimaryKeyValue()で
entityから値をGetするところをPKでなく、ユニーク制約カラムのものに
するのがポイントです。


2008/9/3 土居俊彦 <[E-MAIL ADDRESS DELETED]>:
> 久保(jflute)さん
>
> 土居です。
>
> 今のところ、DBFluteが出力するXMLを手で修正して外部キーを設定することで、とりあえず回避できています。
>
> ただ、replace-schema実行時に毎回修正が必要となるので、自分で実装する方法も検討してみたいと思います。
>
> ありがとうございます。
>
> 08/09/02 に kubo<[E-MAIL ADDRESS DELETED]> さんは書きました:
>> 久保(jflute)です。
>>
>> >> A. PK無しでユニーク制約キーだけあって、それをFKしてる
>> >> B. PKは別に存在している
>> > 「B. PKは別に存在している」です。
>>
>> 了解です。ありがとうございます。
>> もし「A」だったら、
>> ユニークキーをadditionalPrimaryKeyとして
>> DBFluteの中だけでPKとして取り扱うようにすれば
>> 回避できるかなと思ったのですが、「B」でそれを
>> やるとPK定義が重複してへんな動きになりそうですね。
>>
>> 今、実現可能性を検討しているのですが、
>> 申し訳ありませんが、少なくともすぐに
>> どうにかなるようなものではなさそうです。
>> 引き続き検討はしていきますが、
>> 一つ思いついた回避策を提示しておきます。
>> (実際に試してはいないです)
>>
>> additionalForeignKeyでFK先がユニーク制約だと
>> loadReferrerが生成されない件ですが、
>> ExtendedのBehaviorの直接自分で実装してしまうやり方が考えられます。
>> 他のloadXxxList()メソッドを参考に作成すればいけるかもしれません。
>> ちょっと実装を把握するのが大変ですが、ひとまず回避策として。
>> (additionalForeignKey + 独自でload実装)
>
>
> --
> 土居俊彦(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
>