[seasar-dotnet:1876] Re: [DBFlute.NET]業務的one-to-oneな条件に他テーブルのカラム値指定

kubo [E-MAIL ADDRESS DELETED]
2010年 10月 12日 (火) 21:57:23 JST


久保(jflute)です。

SNAPSHOTを更新しました。
バグを修正しています。
以下のように foreignTable を乱打しても大丈夫のようにしました。
(冗長な join 句が出力されないようにもしています)

    ; FK_MEMBER_MEMBER_LOGIN_FOREIGN_FOREIGN_VARIOUS_OVER_TEST = map:{
        ; localTableName  = MEMBER    ; foreignTableName  = MEMBER_LOGIN
        ; localColumnName = MEMBER_ID ; foreignColumnName = MEMBER_ID
        ; fixedCondition =
     $$over($foreignTable.member.memberStatus)$$.DISPLAY_ORDER is not null
 and $$over($foreignTable.member.memberWithdrawalAsOne)$$.WITHDRAWAL_DATETIME
is not null
 and $$over($foreignTable.memberStatus, DISPLAY_ORDER)$$.STATUS_ORDER
is not null
 and $$over($foreignTable.member.memberWithdrawalAsOne.withdrawalReason,
DISPLAY_ORDER)$$.REASON_ORDER is not null
 and $$over($foreignTable.memberStatus)$$.MEMBER_STATUS_NAME is not null
 and $$over(PURCHASE.product.productStatus)$$.PRODUCT_STATUS_NAME is not null
        ; fixedSuffix = AsForeignForeignVariousOverTest
    }


2010/10/12 fp <[E-MAIL ADDRESS DELETED]>:
> fpです。
>
> 久保さん、こんにちは。
>
> ありがとうございます。
>
> 確認させて頂きます。
>
> とても迅速な公開、痛み入ります。
>
>
> (2010/10/12 16:45), kubo wrote:
>> 久保(jflute)です。
>>
>> fpさん、こんにちは
>> 対応したSNAPSHOTを公開しました。
>> (新規クラスファイルが追加されていますのでご注意を)
>>
>> dfnet-basic-example の dfprop も追加されています。
>> WxBizOneToOneTest.cs にてテストしています。
>>
>> ドキュメントも更新しています。
>> (急いで書いたので日本語変かも...)
>> http://dbflute.sandbox.seasar.org/ja/manual/function/genbafit/implfit/bizonetoone/index.html#over
>>
>> ぜひご確認下さい。
>>
>> 2010/10/12 fp<[E-MAIL ADDRESS DELETED]>:
>>> fpです。
>>>
>>> 久保さん、こんにちは。
>>>
>>> 大いに活用します。ありがとうございます。
>>>
>>>> $foreignTableの後ろのDISPLAY_ORDERをパースして
>>>> 取り出して、インラインビューの select 句に指定しています。
>>>> MEMBER_LOGINに同名のカラムがあるとだめですが、
>>>> "select * " をするよりかは遥かにバッティングの可能性は減るかと。
>>>> (オプションのような形式でエリアス名を指定する拡張を
>>>> 後で入れようと思えば入れられるような構造になっています)
>>>
>>> fixedCondition の OverRelation のカラムは on句の絞込み条件
>>> での使用に限定されますから独自のエリアス名で補完すれば
>>> バッティングもなくなりますね。
>>>
>>> (2010/10/12 3:28), kubo wrote:
>>>> 久保(jflute)です。
>>>>
>>>> fpさん、お気遣いありがとうございます。
>>>> まあ、業務的one-to-oneもこれだけ使われれば喜ぶと思うので。
>>>> (他ではなかなか無いDBFluteらしい機能でもあるし)
>>>>
>>>> そして、ひとまず Java の方では落ち着きました。
>>>> LocalTable や ForeignTable を指定するときは、
>>>> $localTable、$foreignTable というように定数指定にし、
>>>> ReferrerTable の時だけテーブル名そのままにしました。
>>>> (そうすることで、もっと曖昧さがなくなるかと)
>>>>
>>>> ; FK_MEMBER_MEMBER_LOGIN_FOREIGN_FOREIGN_OVER_TEST = map:{
>>>>       ; localTableName  = MEMBER    ; foreignTableName  = MEMBER_LOGIN
>>>>       ; localColumnName = MEMBER_ID ; foreignColumnName = MEMBER_ID
>>>>       ; fixedCondition =
>>>>    $$over($localTable.memberStatus)$$.DISPLAY_ORDER
>>>>           = $$over($foreignTable.memberStatus)$$.DISPLAY_ORDER
>>>>       ; fixedSuffix = AsForeignForeignOverTest
>>>> }
>>>>
>>>> そして、$foreignTable を指定すると、
>>>> 以下のようなSQLに自動解決されます。
>>>>
>>>>     from member dflocal
>>>>       left outer join member_status dfrelation_0 on
>>>> dflocal.MEMBER_STATUS_CODE = dfrelation_0.MEMBER_STATUS_CODE
>>>>       left outer join (select dffixedbase.*, dffixedjoin_0_0.DISPLAY_ORDER
>>>>                          from member_login dffixedbase
>>>>                            left outer join member_status dffixedjoin_0_0
>>>> on dffixedbase.LOGIN_MEMBER_STATUS_CODE =
>>>> dffixedjoin_0_0.MEMBER_STATUS_CODE
>>>>                       ) dfrelation_4
>>>>         on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>        and dfrelation_0.DISPLAY_ORDER = dfrelation_4.DISPLAY_ORDER
>>>>
>>>> $foreignTableの後ろのDISPLAY_ORDERをパースして
>>>> 取り出して、インラインビューの select 句に指定しています。
>>>> MEMBER_LOGINに同名のカラムがあるとだめですが、
>>>> "select * " をするよりかは遥かにバッティングの可能性は減るかと。
>>>> (オプションのような形式でエリアス名を指定する拡張を
>>>> 後で入れようと思えば入れられるような構造になっています)
>>>>
>>>> 一旦、この段階でDBFlute.NETの方への移植をします。
>>>> (結構、たくさん修正しているのである程度時間掛かります)
>>>>
>>>> ちなみに、上記の $foreignTable のインラインビュー方式を
>>>> fpさんの業務で活用することはできますでしょうか?
>>>>
>>>> 2010/10/12 fp<[E-MAIL ADDRESS DELETED]>:
>>>>> fpです。
>>>>>
>>>>> 久保さん、ありがとうございます。
>>>>>
>>>>> 無理のない範囲で宜しくお願いします。
>>>>> (既に大抵無理言ってしまってますが)
>>>>>
>>>>> (2010/10/12 1:03), kubo wrote:
>>>>>> 久保(jflute)です。
>>>>>>
>>>>>>> 私の想定するSQLは単純に以下の通りです。
>>>>>>>
>>>>>>> select ...
>>>>>>>     from MEMBER dflocal
>>>>>>>       left outer join MEMBER_LOGIN dfrelation_4
>>>>>>>         on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>>>>       left outer join MEMBER_STATUS dfrelation_4_1
>>>>>>>         on dfrelation_4.LOGIN_MEMBER_STATUS_CODE =
>>>>>>> dfrelation_4_1.MEMBER_STATUS_CODE
>>>>>>>        and dfrelation_4_1.DISPLAY_ORDER = 2
>>>>>>
>>>>>> なるほど、MEMBER_LOGIN の自体の on 句に入るのではなく、
>>>>>> その先のMEMBER_STATUS の on 句に指定した条件を入れる
>>>>>> イメージでしたか。で、そのように条件付けると、
>>>>>> 業務的には MEMBER からone-to-oneになると。
>>>>>>
>>>>>> fixedConditionは、現状ではMEMBER_LOGIN の join の on 句の
>>>>>> 条件を指定することが大前提となっていますので、その土台のまま
>>>>>> ではそのようなSQLは作ることはできません。
>>>>>> なので、実現するには MEMBER_STATUS の on 句の方に
>>>>>> 指定できるような新しい仕組みが必要ですね。
>>>>>> 考えられるのが以下のパターン:
>>>>>>
>>>>>> A. MEMBER_LOGIN の on 句に条件を入れるパターン(通常)
>>>>>> B. MEMBER_STATUS の on 句に条件を入れるパターン(新)
>>>>>> C. 両方の on 句に条件を入れるパターン(新)
>>>>>> D. Cに加えて、さらに先の関連テーブルにも入れるパターン(新)
>>>>>>
>>>>>> fpさんの要件では B というところですね。
>>>>>> これはこれで、ほぼ新機能と言っていいもので、
>>>>>> 特に「dfpropでどう指定させるのか」を
>>>>>> 時間掛けて練る必要がありそうです。
>>>>>> (fixedConditionに加えてoverConditionという項目を追加とか、
>>>>>> fixedConditionの中で自動判別させて条件の嫁ぎ先を決定するとか)
>>>>>>
>>>>>> とりあえずは一旦、上記以外のパターンの実装を固めて、
>>>>>> SNAPSHOT 出したいと思います。上記以外のパターンだけでも
>>>>>> 業務的one-to-oneがしっかりと使えるように。
>>>>>> (どうしても Java to C# で、ちょっとC#版が遅れるので段階的に)
>>>>>>
>>>>>> また、ひとまず以下のようなSQLが自動解決できれば、
>>>>>> それはそれで役に立ちそうなので、できるようにしてみようかと。
>>>>>> (一応、B のパターンと同じ動作になり得るかなと)
>>>>>>
>>>>>> select *
>>>>>>     from member dflocal
>>>>>>       left outer join
>>>>>>         (select MEMBER_LOGIN.*, dfrelation_4_1.DISPLAY_ORDER
>>>>>>            from MEMBER_LOGIN
>>>>>>            left outer join MEMBER_STATUS dfrelation_4_1
>>>>>>              on MEMBER_LOGIN.LOGIN_MEMBER_STATUS_CODE =
>>>>>> dfrelation_4_1.MEMBER_STATUS_CODE
>>>>>>         ) dfrelation_4
>>>>>>         on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>>>        and dfrelation_4.DISPLAY_ORDER = 2
>>>>>>
>>>>>> dfprop において、fixedConditionの中に
>>>>>> $$over(!foreignTable!.memberStatus)$$.DISPLAY_ORDER
>>>>>> というように指定があれば、InlineViewを自動で展開して、
>>>>>> DISPLAY_ORDER だけを select 句に追加して、
>>>>>> MEMBER_LOGINのエリアス名経由でDISPLAY_ORDERが
>>>>>> 利用できるように。
>>>>>> (って書いておいてできなかったりして...一応半分くらいできてて)
>>>>>>
>>>>>> 2010/10/11 fp<[E-MAIL ADDRESS DELETED]>:
>>>>>>> fpです。
>>>>>>>
>>>>>>> 久保さん、こんばんは、ありがとうございます。
>>>>>>>
>>>>>>> 今まで良く分かっていなかったのですが、
>>>>>>> このレスで何となく久保さんの仰る曖昧さの意味が
>>>>>>> 分かったような気がします。
>>>>>>> ほんと申し訳ありません。
>>>>>>>
>>>>>>> 「二つの left outer join が、互いに参照し合う」
>>>>>>> というのが問題ですね。
>>>>>>>
>>>>>>> 私の想定するSQLは単純に以下の通りです。
>>>>>>>
>>>>>>> select ...
>>>>>>>     from MEMBER dflocal
>>>>>>>       left outer join MEMBER_LOGIN dfrelation_4
>>>>>>>         on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>>>>       left outer join MEMBER_STATUS dfrelation_4_1
>>>>>>>         on dfrelation_4.LOGIN_MEMBER_STATUS_CODE =
>>>>>>> dfrelation_4_1.MEMBER_STATUS_CODE
>>>>>>>        and dfrelation_4_1.DISPLAY_ORDER = 2
>>>>>>>
>>>>>>> イメージとしては、dfpropで
>>>>>>> $$over($$foreignAlias$$.overRelationAlias)$$
>>>>>>> と指定したら
>>>>>>>
>>>>>>> $$localAlias$$
>>>>>>> left outer join
>>>>>>> $$foreignAlias$$
>>>>>>>     on $$localAlias$$.ID = $$foreignAlias$$.ID
>>>>>>> left outer join
>>>>>>> $$overRelationAlias$$
>>>>>>>     on $$foreignAlias$$.overRelationAlias_ID = $$overRelationAlias$$.ID
>>>>>>> and [fixedCondition]
>>>>>>>
>>>>>>> です。
>>>>>>>
>>>>>>> $$over($$localAlias$$.overRelationAlias)$$
>>>>>>> なら
>>>>>>>
>>>>>>> $$localAlias$$
>>>>>>> left outer join
>>>>>>> $$foreignAlias$$
>>>>>>>     on $$localAlias$$.ID = $$foreignAlias$$.ID
>>>>>>> left outer join
>>>>>>> $$overRelationAlias$$
>>>>>>>     on $$localAlias$$.overRelationAlias_ID = $$overRelationAlias$$.ID
>>>>>>> and [fixedCondition]
>>>>>>>
>>>>>>> で、
>>>>>>> $$over(dflocal.overRelationAlias)$$
>>>>>>> なら
>>>>>>>
>>>>>>> from dflocal
>>>>>>> left outer join
>>>>>>> $$localAlias$$
>>>>>>>     on dflocal.localAlias_ID = $$localAlias$$.ID
>>>>>>> left outer join
>>>>>>> $$foreignAlias$$
>>>>>>>     on $$localAlias$$.ID = $$foreignAlias$$.ID
>>>>>>> left outer join
>>>>>>> $$overRelationAlias$$
>>>>>>>     on dflocal.overRelationAlias_ID = $$overRelationAlias$$.ID
>>>>>>> and [fixedCondition]
>>>>>>>
>>>>>>> で、いけるのかなと。
>>>>>>>
>>>>>>> ※  [fixedCondition]は
>>>>>>>       $$overRelationAlias$$.XxxColumn = $cls(XxxType.XxxCode)
>>>>>>> とか
>>>>>>>       $$foreignAlias$$.XxxColumn = $$overRelationAlias$$.XxxColumn
>>>>>>> とか
>>>>>>>       $$localAlias$$.XxxColumn<= $$overRelationAlias$$.XxxColumn
>>>>>>> とか
>>>>>>>       dflocal.XxxColumn>= $$overRelationAlias$$.XxxColumn
>>>>>>> です。
>>>>>>>
>>>>>>> 長々とすみません。宜しくお願いします。
>>>>>>>
>>>>>>>
>>>>>>> (2010/10/11 22:37), kubo wrote:
>>>>>>>> 久保(jflute)です。
>>>>>>>>
>>>>>>>> fpさん、もうちょっとアドバイス頂ければと思います。
>>>>>>>> 定義した業務的one-to-oneの foreignTable を経由した
>>>>>>>> さらなる foreignTable のカラムを fixedCondition に
>>>>>>>> 利用するパターンですが、二つの left outer join が、
>>>>>>>> 互いに参照し合うのでSQL的に動作するのかどうか、
>>>>>>>> ちょっと疑問に思っています。
>>>>>>>>
>>>>>>>> local = MEMBER
>>>>>>>> foreign = MEMBER_LOGIN (業務的one-to-one)
>>>>>>>> foreignのforeign = MEMBER_STATUS (LOGIN経由)
>>>>>>>>
>>>>>>>> select ...
>>>>>>>>       from member dflocal
>>>>>>>>         left outer join MEMBER_STATUS dfrelation_4_1
>>>>>>>>           on dfrelation_4.LOGIN_MEMBER_STATUS_CODE =
>>>>>>>> dfrelation_4_1.MEMBER_STATUS_CODE
>>>>>>>>         left outer join MEMBER_LOGIN dfrelation_4
>>>>>>>>           on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>>>>>          and dfrelation_4_1.DISPLAY_ORDER = 2
>>>>>>>>
>>>>>>>> だと、MEMBER_STATUS の left outer join が先に来て、
>>>>>>>> dfrelation_4 が(まだ)解決できません。順番を逆にしても:
>>>>>>>>
>>>>>>>> select ...
>>>>>>>>       from member dflocal
>>>>>>>>         left outer join MEMBER_LOGIN dfrelation_4
>>>>>>>>           on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>>>>>          and dfrelation_4_1.DISPLAY_ORDER = 2
>>>>>>>>         left outer join MEMBER_STATUS dfrelation_4_1
>>>>>>>>           on dfrelation_4.LOGIN_MEMBER_STATUS_CODE =
>>>>>>>> dfrelation_4_1.MEMBER_STATUS_CODE
>>>>>>>>
>>>>>>>> 今度は、MEMBER_LOGIN の on 句で、
>>>>>>>> dfrelation_4_1 が解決できません。
>>>>>>>> MySQLとPostgreSQLで実際に試してエラーになりました。
>>>>>>>>
>>>>>>>> 頭の中でいけるかなぁと勝手に思っていはいたのですが、
>>>>>>>> いざやってみると確かに...。
>>>>>>>> ちょっと自分が勘違いしているかもしれません。
>>>>>>>> fpさんのところで実業務で想定しているパターンを
>>>>>>>> もう少し情報頂けないでしょうか?
>>>>>>>> (どういうSQLを想定されていますでしょうか!?)
>>>>>>>>
>>>>>>>> #
>>>>>>>> # 以下のようにすれば、いけそうですが、
>>>>>>>> # 同名カラムをどう解決したものかってとこですね...
>>>>>>>> #
>>>>>>>>
>>>>>>>> select *
>>>>>>>>       from member dflocal
>>>>>>>>         left outer join
>>>>>>>>           (select *
>>>>>>>>              from MEMBER_LOGIN
>>>>>>>>              left outer join MEMBER_STATUS dfrelation_4_1
>>>>>>>>                on MEMBER_LOGIN.LOGIN_MEMBER_STATUS_CODE =
>>>>>>>> dfrelation_4_1.MEMBER_STATUS_CODE
>>>>>>>>           ) dfrelation_4
>>>>>>>>           on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
>>>>>>>>          and dfrelation_4.DISPLAY_ORDER = 2
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/10/11 fp<[E-MAIL ADDRESS DELETED]>:
>>>>>>>>> fpです。
>>>>>>>>>
>>>>>>>>> ありがとうございます。
>>>>>>>>>
>>>>>>>>> 申し訳ありませんが、宜しくお願いします。
>>>>>>>>>
>>>>>>>>> (2010/10/11 18:46), kubo wrote:
>>>>>>>>>> 久保(jflute)です。
>>>>>>>>>>
>>>>>>>>>>> 当方のプロジェクトでは、話に出た全パターン当てはまります。
>>>>>>>>>> なるほどー、じゃあ頑張りますよぅ。
>>>>>>>>>> こっちも「すぐに使ってもらえないかもしれない機能」を
>>>>>>>>>> 実装するのはリスクがあって、すぐに確認・実践してもらえる
>>>>>>>>>> ことで、要件に合った仕様と品質を担保してから公開できるので。
>>>>>>>>>> (なので、大分安定を重視する時期に来たDBFluteでは要件のない
>>>>>>>>>> 機能はあえて実装せずに将来の機会を待つこともあります、
>>>>>>>>>> 今回のパターンはそのつもりでした...)
>>>>>>>>>> もちろん、実現コストに全て委ねられますが、あともうちょい頑張れば
>>>>>>>>>> できそうなので。(フィルタ処理はコールバックで遅延させます)
>>>>>>>>>>
>>>>>>>>>> 2010/10/11 fp<[E-MAIL ADDRESS DELETED]>:
>>>>>>>>>>> fpです。
>>>>>>>>>>>
>>>>>>>>>>> 久保さん、ありがとうございます。
>>>>>>>>>>>
>>>>>>>>>>> 当方のプロジェクトでは、話に出た全パターン当てはまります。
>>>>>>>>>>>
>>>>>>>>>>> ただ、無理なようでしたら機能制限の範囲内で回避策を
>>>>>>>>>>> 考えますので、それほど緊急とはお考えにならないで下さい。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> すれちがってしまいましたね。>[seasar-dotnet:1861]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (2010/10/11 18:26), kubo wrote:
>>>>>>>>>>>> 久保(jflute)です。
>>>>>>>>>>>>
>>>>>>>>>>>> ああ、なるほど、業務的one-to-oneのリレーションを
>>>>>>>>>>>> 通過した先の foreignTable のことですね。
>>>>>>>>>>>> しかも、今の仕様だと辿るリレーションの中で、
>>>>>>>>>>>> 業務的one-to-oneを含めることができないので、
>>>>>>>>>>>> 参照元テーブルから辿ることもできないですね。
>>>>>>>>>>>>
>>>>>>>>>>>> 業務的one-to-oneの参照先テーブルだけは特別に、
>>>>>>>>>>>> ポイントとして指定できる唯一の foreignTable、
>>>>>>>>>>>> もしくは、リレーションで特別に辿れる業務的one-to-one
>>>>>>>>>>>> というように扱えればってところですね。
>>>>>>>>>>>>
>>>>>>>>>>>> $$over(MEMBER_LOGIN.memberStatus)$$
>>>>>>>>>>>>
>>>>>>>>>>>>         もしくは
>>>>>>>>>>>>
>>>>>>>>>>>> $$over(MEMBER.memberLoginAsValid.memberStatus)$$
>>>>>>>>>>>>
>>>>>>>>>>>> 該当の業務的one-to-oneが確定していない時点で、その奥の
>>>>>>>>>>>> リレーションを有効にしてエリアス名を取得できるかどうか、
>>>>>>>>>>>> その辺が実現の鍵になるので、ちょっと考えますね。
>>>>>>>>>>>> (場合に寄っては、置換処理をコールバックで遅延させて
>>>>>>>>>>>> 実行させるなどの工夫が必要かも...)
>>>>>>>>>>>>
>>>>>>>>>>>> ちなみに、fp さんの業務の中で、このパターンに
>>>>>>>>>>>> 当てはまるものがありますでしょうか?
>>>>>>>>>>>>
>>>>>>>>>>>> 2010/10/11 fp<[E-MAIL ADDRESS DELETED]>:
>>>>>>>>>>>>> fpです。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 「OverRelation」を使わずに以下のようにできることは
>>>>>>>>>>>>> 認識しています。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ; FK_MEMBER_MEMBER_LOGIN_AS_VALID = map:{
>>>>>>>>>>>>>           ; localTableName  = MEMBER    ; foreignTableName  = MEMBER_LOGIN
>>>>>>>>>>>>>           ; localColumnName = MEMBER_ID ; foreignColumnName = MEMBER_ID
>>>>>>>>>>>>>           ; fixedCondition =
>>>>>>>>>>>>>             exists(select 'TRUE' from MEMBER_STATUS st
>>>>>>>>>>>>>                     where $$foreignAlias$$.LOGIN_MEMBER_STATUS_CODE =
>>>>>>>>>>>>>                           st.MEMBER_STATUS_CODE
>>>>>>>>>>>>>                       and st.DISPLAY_ORDER = 2)
>>>>>>>>>>>>>           ; fixedSuffix = AsValid
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (2010/10/11 16:44), fp wrote:
>>>>>>>>>>>>>> fpです。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 久保さん、即座の御返事ありがとうございます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ん~、dbflute_exampledb にうまい例が見つからないのですが
>>>>>>>>>>>>>> 仮に、MEMBER ->              MEMBER_LOGIN ->              MEMBER_STATUS で
>>>>>>>>>>>>>> MEMBER_STATUS.DISPLAY_ORDER = 2 の条件で
>>>>>>>>>>>>>> MEMBER ->              MEMBER_LOGIN に業務的one-to-oneなFKを設定できる
>>>>>>>>>>>>>> とした場合、
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ; FK_MEMBER_MEMBER_LOGIN_AS_VALID = map:{
>>>>>>>>>>>>>>            ; localTableName  = MEMBER    ; foreignTableName  = MEMBER_LOGIN
>>>>>>>>>>>>>>            ; localColumnName = MEMBER_ID ; foreignColumnName = MEMBER_ID
>>>>>>>>>>>>>>            ; fixedCondition =
>>>>>>>>>>>>>>                $$over(MEMBER_LOGIN.memberStatus)$$.DISPLAY_ORDER = 2
>>>>>>>>>>>>>>            ; fixedSuffix = AsValid
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> と書きたい、ということです。
>>>>>>>>>>>>>> 定義上明示されている MEMBER_LOGIN をポイントテーブルと
>>>>>>>>>>>>>> することに曖昧さがあるとは思わないのですが。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> いままさに定義しようとしているリレーションのための
>>>>>>>>>>>>>> 条件の指定に、以下は適用できませんし。
>>>>>>>>>>>>>>> MEMBER.memberStatusByFooCode というように、
>>>>>>>>>>>>>>> 明示的にリレーションを書いてもらう仕様にしています。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> foreignTable についての認識に齟齬があるのでしょうか?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (2010/10/11 15:56), kubo wrote:
>>>>>>>>>>>>>>> 久保(jflute)です。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> とはいえ、foreignTable をポイントとすることはできないでしょうか?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 例えば、会員に会員ステータスへのFKカラムが二つあった場合、
>>>>>>>>>>>>>>> ポイントを会員ステータスにするとになります。
>>>>>>>>>>>>>>> なので、foreignTableに関しては、
>>>>>>>>>>>>>>> MEMBER.memberStatusByFooCode というように、
>>>>>>>>>>>>>>> 明示的にリレーションを書いてもらう仕様にしています。
>>>>>>>>>>>>>>> 親の親の親の親の親のカラムとかになると、指定が長くて
>>>>>>>>>>>>>>> 大変ですが、曖昧さの可能性も増えるので、
>>>>>>>>>>>>>>> そこの優先度を練り直したって感じです。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ポイントテーブルは ORDER_ITEM で、リレーションは order。
>>>>>>>>>>>>>>>>>           ->                 $$over(ORDER_ITEM.order)$$
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> これは実際の構成ではなく、あくまで例ってことで (^^;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> おっと、そうでしたかぁ、失敬w
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> seasar-dotnet mailing list
>>>>>>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> seasar-dotnet mailing list
>>>>>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> seasar-dotnet mailing list
>>>>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> seasar-dotnet mailing list
>>>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> seasar-dotnet mailing list
>>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> seasar-dotnet mailing list
>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seasar-dotnet mailing list
>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>>
>>>>>> _______________________________________________
>>>>>> seasar-dotnet mailing list
>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>
>>>>> _______________________________________________
>>>>> seasar-dotnet mailing list
>>>>> [E-MAIL ADDRESS DELETED]
>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>
>>>> _______________________________________________
>>>> seasar-dotnet mailing list
>>>> [E-MAIL ADDRESS DELETED]
>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>>> _______________________________________________
>>> seasar-dotnet mailing list
>>> [E-MAIL ADDRESS DELETED]
>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>> _______________________________________________
>> seasar-dotnet mailing list
>> [E-MAIL ADDRESS DELETED]
>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>


seasar-dotnet メーリングリストの案内