[Seasar-user:20431] Re: DBFluteのadditionalForeignKeyについて
kubo
[E-MAIL ADDRESS DELETED]
2010年 12月 15日 (水) 15:17:43 JST
久保(jflute)です。
こちらの件、先ほどリリースされた、
DBFlute.NET-0.8.9.22 に反映されています。
2010/12/7 kubo <[E-MAIL ADDRESS DELETED]>:
> 久保(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の一要素の場合と、普通のカラムの場合の
>>>> 二種類のテーブルを用意してテストしています。
>>>>
>>
>>
>
Seasar-user メーリングリストの案内