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

[kubo]

久保(jflute)です。

> とはいえ、foreignTable をポイントとすることはできないでしょうか？

例えば、会員に会員ステータスへのFKカラムが二つあった場合、
ポイントを会員ステータスにすると曖昧になります。
なので、foreignTableに関しては、
MEMBER.memberStatusByFooCode というように、
明示的にリレーションを書いてもらう仕様にしています。
親の親の親の親の親のカラムとかになると、指定が長くて
大変ですが、曖昧さの可能性も増えるので、
そこの優先度を練り直したって感じです。

>> ポイントテーブルは ORDER_ITEM で、リレーションは order。
>>   ->  $$over(ORDER_ITEM.order)$$
>
> これは実際の構成ではなく、あくまで例ってことで (^^;

おっと、そうでしたかぁ、失敬w

2010/10/11 fp <[E-MAIL ADDRESS DELETED]>:
> fpです。
>
> 久保さん、こんにちは。
>
> 練り直し、ありがとうございます。
> 「基点テーブル限定パターン」はイメージ通りになりました。
>
> 「曖昧さをより無くす方を優先する仕様」における機能制限
> も理解できます。
>
> とはいえ、foreignTable をポイントとすることはできないでしょうか？
>> ポイントとなるテーブルは、Local もしくは、Referrer のみで、
>> そこから対象となるテーブルまでのリレーションを全て記述する
>
>> 形式にしました。とは言っても、fpさんのパターンの場合は、
>> 指定方法に何も変わりはないです。
>> ポイントテーブルは ORDER_ITEM で、リレーションは order。
>>   ->  $$over(ORDER_ITEM.order)$$
>
> これは実際の構成ではなく、あくまで例ってことで (^^;
>
> 宜しくお願い致します。
>
>
> (2010/10/11 3:06), kubo wrote:
>> 久保(jflute)です。
>>
>> ご確認・ご指摘ありがとうございます。
>> なぜか頭の中で $$localAlias$$ と勘違いしてて、
>> Referrer自身のカラムの考慮が抜けてました。
>>
>> で、再度練り直したのですが、
>> 指定方法を簡易にすることを優先した仕様になっていましたが、
>> 曖昧さをより無くす方を優先する仕様に直しました。
>> ドキュメント更新されていますのでご覧下さい。
>>
>> http://dbflute.sandbox.seasar.org/ja/manual/function/genbafit/implfit/bizonetoone/index.html#over
>>
>> 具体的には、ポイントとなるテーブルを探すのではなく、
>> ポイントとなるテーブルは、Local もしくは、Referrer のみで、
>> そこから対象となるテーブルまでのリレーションを全て記述する
>> 形式にしました。とは言っても、fpさんのパターンの場合は、
>> 指定方法に何も変わりはないです。
>> ポイントテーブルは ORDER_ITEM で、リレーションは order。
>>   ->  $$over(ORDER_ITEM.order)$$
>>
>> SNAPSHOTが上書きされています。
>> お手数ですが、こちらで再度確認して頂けるとありがたいです。
>>
>> 2010/10/10 takashi.nishikawa<[E-MAIL ADDRESS DELETED]>:
>>> fpです。
>>>
>>> 申し訳ありません。
>>> 先刻のメール[seasar-dotnet:1853]の日時、
>>> クライアントPCの日付がおかしくなっていました。
>>>
>>> (2010/10/01 16:00), fp wrote:
>>>> fpです。
>>>>
>>>> 久保さん、ありがとうございます。
>>>>
>>>> ドキュメントの整備まで迅速な対応、痛み入ります。
>>>> ドキュメント等を読んで改めて大変な処理をお願いしたと
>>>> 思いました。
>>>>
>>>> 早速試してみましたところ、ドキュメントの説明どおり
>>>> $$over([テーブル名].[リレーション名])$$ と設定すれば
>>>> 問題なく動作しました。
>>>>
>>>> ところで、PURCHASE 基点で PURCHASE_DATETIME 時点の
>>>> MEMBER_ADDRESS を特定する場合の fixedCondition は
>>>> 「OverRelation」ではなく「dflocal」決め打ちとする
>>>> のでしょうか？
>>>>
>>>> 宜しくお願いします。
>>>>
>>>>
>>>> (2010/10/09 10:39), kubo wrote:
>>>>> 久保(jflute)です。
>>>>>
>>>>> OverRelation (と命名しました) を対応しました。
>>>>> DBFlute.NET-0.8.9.20-SNAPSHOTをお試し下さい。
>>>>>
>>>>> // SNAPSHOT がダウンロード可能
>>>>> http://dbflute.net.sandbox.seasar.org/ja/environment/newest.html
>>>>>
>>>>> // 該当箇所を説明したドキュメント
>>>>> http://dbflute.sandbox.seasar.org/ja/manual/function/genbafit/implfit/bizonetoone/index.html#over
>>>>>
>>>>> dfnet-basic-example でもテスト用のExampleがあります。
>>>>> (additionalForeignKeyMap.dfprop にて実際に利用)
>>>>>
>>>>> なかなか仕様的な割り切りと調整が悩ましかったですが、
>>>>> (特にどうしても階層制限を入れざるを得なかったところとか)
>>>>> いざとなれば、ExConditionQuery にてオーバーライドで
>>>>> 独自の調整できるような形にもなっています。
>>>>> 処理メソッドを整理して virtual に：
>>>>> AbstractConditionQuery.resolveFixedCondition()
>>>>> AbstractConditionQuery.resolveFixedConditionOverRelation()
>>>>> ※かなり大変な処理になっていますが...
>>>>> _______________________________________________
>>>>> 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
>