additionalForeignKeyMap.dfpropでfixedConditionの指定だけで擬似FK

[awaawa]

jfluteさん

awaawaです。

additionalForeignKeyMap.dfpropで
fixedConditionの指定だけ(※)で、擬似FKを設定できるようにしていただきたいのですが、
可能でしょうか。(実装上というより、ポリシー上)
※もしくは、localColumnName、foreignColumnNameでデータを(関数で)加工出来るように。

イレギュラーな内容なので、自動生成後にGapクラスでOverrideして何とかしようと思ったのですが、
出来なかったので。
外出しにすると、ほかの関連テーブルの取得に大分コストがかかるので避けたいと思っています。

【テーブル、データのイメージ】
・IDの決まった一部が違うデータでも業務的に関連があり、
　自システムのテーブルAのIDと別システムのテーブルCのIDを紐付けたい。
　(C.ID = SUBSTR(A.ID, 1, 5) || 'B')

自システムのテーブルAのID
11111A、11112A

別システムのテーブルBのID
11111A、11112A、11111B、11112B

別システムのテーブルCのID
11111B、11112B

別システムのテーブルCのID
11111A、11112A

ご確認よろしくお願いします。

[kubo]

jfluteです。

awaawaさん、こんばんは

まずは、その関連のギャップを埋めるVIEWを作って、
それ経由で取得するとかはできないかな！？

できなければ、AbstractSqlClauseの
buildLeftOuterJoinClause() をもうちょっと細かく
メソッド分けして拡張しやすいようにしようかと。

dfpropの方や、CQの方だとカラムはしっかりカラム
じゃないとダメなので、最後のところでフィルタかける
のがいいのかなと。

2011/11/26 awaawa <p1us3i...@gmail.com>:

> --
> このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
> このグループに投稿するには、dbf...@googlegroups.com にメールを送信してください。
> このグループから退会するには、dbflute+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/dbflute?hl=ja からこのグループにアクセスしてください。
>
>

[awaawa]

awaawaです。

VIEWが1番いいのですが、
プロジェクト内でVIEWは基本使わないと決まりがありまして。。。
（方針を変えられるのが1番いいのですが。）

なので、拡張しやすくしていただけるとありがたいです。

On 11月26日, 午後11:47, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> awaawaさん、こんばんは
>
> まずは、その関連のギャップを埋めるVIEWを作って、
> それ経由で取得するとかはできないかな！？
>
> できなければ、AbstractSqlClauseの
> buildLeftOuterJoinClause() をもうちょっと細かく
> メソッド分けして拡張しやすいようにしようかと。
>
> dfpropの方や、CQの方だとカラムはしっかりカラム
> じゃないとダメなので、最後のところでフィルタかける
> のがいいのかなと。
>

> 2011/11/26 awaawa <p1us3inus2...@gmail.com>:

[awaawa]

awaawaです。

ふと思ったのですが、
暗号化、復号化処理で使うGearedCipherManagerとCipherFunctionFilter
を使うといけますかね。
（本来の使い道と異なる使い方になりますが）

明日になりますが確認してみます。

[kubo]

jfluteです。

いや、結合条件は暗号化、復号化をする必要のないところだから、
効かないと思う。というか、効いてもちょっと強引過ぎるかなと。

DBFluteに関係なく、こういうトリッキーな関連がとかがある
ようなDB設計にこそVIEWを使うべきだとは思います。

で、AbstractSqlClauseの結合条件部分だけをオーバーライド
できるようにしたので、試してみてください。
buildJoinOnClause() あたりをみてくれれば。
多分、doBuildJoinOnClauseBasic()で if 文で、
「対象リレーションなら何もしない」ってしちゃって、
fixedConditionで好きなように定義しちゃえばいけるかなぁと。

DBFlute-0.9.9.2B-00-SNAPSHOTにて。
半日早ければ滑り込みだったんだけどね（＾＾
今日中(日中)の確認が欲しいけど、でも機能的な面が
変わったわけではないので、確認が間に合わなくても
こっちの既存テストが通ればリリースしちゃいます。

あと、当然のことながら超内部のメソッドなので、
不意に挙動が変わることがあるのは覚悟の上で。
（JUnit単体テストはめっちゃ書いてください）

2011/11/27 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

> 今日中(日中)の確認が欲しいけど、でも機能的な面が
> 変わったわけではないので、確認が間に合わなくても
> こっちの既存テストが通ればリリースしちゃいます。

と思ったけど、ちょっと都合が変わったので、
ゆっくりでOKです。

2011/11/27 kubo <dbf...@gmail.com>:

[awaawa]

awaawaです。

すいません。
明日の日中（できたら夜中）に確認します。

[kubo]

jfluteです。

やはり、ちょっとリリース固めたので。
もし、何かあればその次のバージョンにて。
なので、いずれにせよ、急がなくてもOKです。

2011/11/27 awaawa <p1us3i...@gmail.com>:

[awaawa]

awaawaです。

取り急ぎの回答になります。
やりたいことができました。ありがとうございます。

念のため、実装方法について確認させてください。
DBFluteConfig.setSqlClauseCreatoer
に
拡張したSqlClauseを返すSqlClauseCreatoerを設定すれば問題ないですよね。

[kubo]

jfluteです。

おお、よかった。確認ありがとう。
DBFluteConfig経由でOKです。
一つのテーブルだけならBsConditionBeanの
createSqlClause()をオーバーライドしても
OKそうだね。

2011/11/28 awaawa <p1us3i...@gmail.com>:

[awaawa]

awaawaです。

jfluteさん、回答ありがとうございます。
やり方あっていて良かったです。

はじめはBsConditionBeanに処理を入れようと思ったのですが、
ImplementedSqlClauseCreatorで
setupSqlClauseOption(sqlClause);
prepareSupporterComponent(sqlClause);
の初期化処理があったため、
DBFluteConfig経由にしました。
これでいきます！
（対象のイレギュラーなリレーションにアクセスする処理が複数あり、
処理ごとに基点テーブルが違うと複数のBsConditionBeanの修正が必要にもなりますし）

On 11月28日, 午後8:36, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> おお、よかった。確認ありがとう。
> DBFluteConfig経由でOKです。
> 一つのテーブルだけならBsConditionBeanの
> createSqlClause()をオーバーライドしても
> OKそうだね。
>

> 2011/11/28 awaawa <p1us3inus2...@gmail.com>:

>
>
>
> > awaawaです。
>
> > 取り急ぎの回答になります。
> > やりたいことができました。ありがとうございます。
>
> > 念のため、実装方法について確認させてください。
> > DBFluteConfig.setSqlClauseCreatoer
> > に
> > 拡張したSqlClauseを返すSqlClauseCreatoerを設定すれば問題ないですよね。
>

> > On 2011/11/27, at 17:09, kubo <dbfl...@gmail.com> wrote:
>
> >> jfluteです。
>
> >> やはり、ちょっとリリース固めたので。
> >> もし、何かあればその次のバージョンにて。
> >> なので、いずれにせよ、急がなくてもOKです。
>

> >> 2011/11/27 awaawa <p1us3inus2...@gmail.com>:

> >>> awaawaです。
>
> >>> すいません。
> >>> 明日の日中（できたら夜中）に確認します。
>

> >>> On 2011/11/27, at 12:13, kubo <dbfl...@gmail.com> wrote:
>
> >>>> jfluteです。
>
> >>>>> 今日中(日中)の確認が欲しいけど、でも機能的な面が
> >>>>> 変わったわけではないので、確認が間に合わなくても
> >>>>> こっちの既存テストが通ればリリースしちゃいます。
>
> >>>> と思ったけど、ちょっと都合が変わったので、
> >>>> ゆっくりでOKです。
>

> >>>> 2011/11/27 kubo <dbfl...@gmail.com>:

> >>>>> jfluteです。
>
> >>>>> いや、結合条件は暗号化、復号化をする必要のないところだから、
> >>>>> 効かないと思う。というか、効いてもちょっと強引過ぎるかなと。
>
> >>>>> DBFluteに関係なく、こういうトリッキーな関連がとかがある
> >>>>> ようなDB設計にこそVIEWを使うべきだとは思います。
>
> >>>>> で、AbstractSqlClauseの結合条件部分だけをオーバーライド
> >>>>> できるようにしたので、試してみてください。
> >>>>> buildJoinOnClause() あたりをみてくれれば。
> >>>>> 多分、doBuildJoinOnClauseBasic()で if 文で、
> >>>>> 「対象リレーションなら何もしない」ってしちゃって、
> >>>>> fixedConditionで好きなように定義しちゃえばいけるかなぁと。
>
> >>>>> DBFlute-0.9.9.2B-00-SNAPSHOTにて。
> >>>>> 半日早ければ滑り込みだったんだけどね（＾＾
> >>>>> 今日中(日中)の確認が欲しいけど、でも機能的な面が
> >>>>> 変わったわけではないので、確認が間に合わなくても
> >>>>> こっちの既存テストが通ればリリースしちゃいます。
>
> >>>>> あと、当然のことながら超内部のメソッドなので、
> >>>>> 不意に挙動が変わることがあるのは覚悟の上で。
> >>>>> （JUnit単体テストはめっちゃ書いてください）
>

> >>>>> 2011/11/27 awaawa <p1us3inus2...@gmail.com>:

[kubo]

jfluteです。

> はじめはBsConditionBeanに処理を入れようと思ったのですが、
> ImplementedSqlClauseCreatorで
> setupSqlClauseOption(sqlClause);
> prepareSupporterComponent(sqlClause);
> の初期化処理があったため、
> DBFluteConfig経由にしました。

お、なるほど、そうか。
じゃあ、やっぱり DBFluteConfig がいいね。
(この機能が役に立つときが来るとは思わなかった...)

2011/11/29 awaawa <p1us3i...@gmail.com>: