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

[fp]

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