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

kubo [E-MAIL ADDRESS DELETED]
2010年 10月 11日 (月) 18:46:13 JST


久保(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 メーリングリストの案内