[Seasar-user:20395] Re: DBFluteのadditionalForeignKeyについて

[kubo]

久保(jflute)です。

すいません、また個人宛に送ってしまいました。
(Replyで個人アドレスが to になってしまいました)

> ご対応有難う御座いました。
> 正常に出力されることを確認しました。
> これからもお世話になることがあるかもしれませんが、
> 宜しくお願いします。

桑田さん、ご確認ありがとうございます。
ドキュメントはまだですが、非推奨構造フォロー
という形でページを作成する予定です。
かなり見つかりにくい現象でしたが、
桑田さんのおかげでDBFluteの幅が広がりました。
ありがとうございます。

2010/12/7 kuwata <[E-MAIL ADDRESS DELETED]>:
> お世話になります、桑田です。
>
> ご対応有難う御座いました。
> 正常に出力されることを確認しました。
> これからもお世話になることがあるかもしれませんが、
> 宜しくお願いします。
>
> ※ちなみにメーリングリスト経由ではないようですが、
> 　宜しいのでしょうか
>
>> 久保(jflute)です。
>>
>> すいません、桑田さんがご利用されているのは、
>> DBFlute.NETの方でしたね。
>> (突っ込まれる前に気付けてよかった...)
>>
>> DBFlute.NET-0.8.9.22-00-SNAPSHOTを公開しました。
>> http://dbflute.net.sandbox.seasar.org/ja/environment/newest.html#snapshot
>>
>> 2010/12/7 kubo<[E-MAIL ADDRESS DELETED]>:
>>>
>>> 久保(jflute)です。
>>>
>>> 桑田さん、再現テーブルのコードありがとうございます。
>>> こちらでも再現致しました。
>>> LocalColumn がPKかそうでないかがポイントでしたね。
>>>
>>> もともとの仕様として、例えば会員と会員住所情報の関係で、
>>> 会員住所情報から会員への(本来あるべき)FK制約が存在して
>>> いない場合に、会員 to 会員住所情報の業務的one-to-oneを
>>> 設定したときに、自動で暗黙のFKを会員住所情報 to 会員に
>>> 付与するようにしています。
>>> (単に、便利にしてるってだけのものではあります)
>>>
>>> そのときの判定で「LocalColumn が全てPKかどうか」
>>> だけで判定してしまっていました。
>>> 「fixedCondition利用 = LocalColumnはPK」
>>> という想定だったのですが、
>>> 業務的many-to-oneで利用する、かつ、
>>> LocalColumnが複合PKの一要素である、
>>> (DBFluteとしては二つの非推奨が重なり)
>>> という状況では間違った判定となり、
>>> 逆参照が付与されてしまいました。正確には、
>>> 「LocalColumnがそのテーブルのPKの全て要素か否か」
>>> と判定しなければなりません。
>>>
>>> 恐らく、ログ(dbflute.log)のAdditionalForeignKeyの
>>> 初期化で「*Reversed FK was also made implicitly」
>>> というログが出力されていたと思います。
>>>
>>> DBFlute-0.9.7.5-05-SNAPSHOTにて修正しました。
>>> (モジュールとランタイム両方)
>>> ぜひ、こちらをご利用下さい。
>>>
>>> dbflute-mysql-exampleも修正しています。
>>> 複合PKの一要素の場合と、普通のカラムの場合の
>>> 二種類のテーブルを用意してテストしています。
>>>
>
>