[seasar-dotnet:1873] Re: [DBFlute.NET]業務的one-to-oneな条件に他テーブルのカラム値指定
fp
[E-MAIL ADDRESS DELETED]
2010年 10月 12日 (火) 16:56:53 JST
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 メーリングリストの案内