[seasar-dotnet:1372] Re: DBFlute：DBFluteConfigの設定の仕方を教えて下さい。

2009年 6月 6日 (土) 13:55:28 JST

久保(jflute)です。

ちょっとExampleを作ってみました。
(Javaですが環境周り参考になると思います。)

dbflute-mysql-example (DBFluteプロジェクト)
dbflute-clientsql-example (メインプロジェクト)

clientsqlプロジェクトは、mysqlプロジェクトを参照していて、
DBFluteモジュールもDBFluteクライアントもありません。
SQLファイルとSql2Entityで生成されたEntityやPmbと
それらを使って外だしSQLを実行するテストがあります。

mysqlプロジェクトは、フルセットでDBFluteの環境が
整っていますが、通常とちょっと違うのが、
sql2entity.shだけでなく、sql2entity-clientsql.shなる
タスク実行ファイルが追加されています。
これは手動で追加したファイルで、中では
「export DBFLUTE_ENVIRONMENT_TYPE=clientsql」
と、タスク実行前に環境変数を一つ設定しています。
また、dfprop配下にclientsqlというフォルダがあって、
幾つかdfpropファイルが配置されています。

このようにすると、sql2entity-clientsql.shの実行時に
dfprop配下のclientsqlのdfpropファイルを優先して参照する
ようになります。要は、clientsqlプロジェクト用の設定で
Sql2Entityを実行することが可能になります。
こちらの記事で紹介されている機能です：
http://d.hatena.ne.jp/jflute/20081025/1224857222
(もともとは主にReplaceSchemaで利用を想定した機能です)

そして、その専用の設定でポイントなのが、
outsideSqlDefinitionMap.dfpropの
「SQLファイルの場所(sqlDirectory)」と
「「Entityの生成先(sql2EntityOutputDirectory)」
がclientsqlプロジェクトのに向けらていることです。
これによりsql2entity-clientsql.shで実行したSql2Entityは
clientsqlプロジェクトのSQLファイルを実行して、
clientsqlプロジェクトにEntityを生成します。

refreshDefinitionMap.dfpropは、リフレッシュする対象の
プロジェクトが変わるの専用の設定になっています。
(Eclipseだけの話なので、DBFlute.NETには無関係)
classificationResource.dfpropは、このdfpropファイルだけ
優先のロジックが間違ってまして(今発見した)、特に
修正している点はないですが冗長に配置しています。
(使ってなければ意識する必要は無いです)

https://www.seasar.org/svn/sandbox/dbflute/trunk/dbflute-mysql-example
https://www.seasar.org/svn/sandbox/dbflute/trunk/dbflute-clientsql-example
をぜひご覧下さい。
(C#の場合はさらにDBFluteConfigのAssemblyの設定が必要になります)

各メインプロジェクトにDBFluteクライアントを置く方法だと、
設定ファイルとかが冗長してしまうので、上記の方法の方が
管理面は良いかと思います。

いずれにせよ、SQLファイルのパス指定をタイプセーフにする
BehaviorQueryPathは利用できない(しづらい)ので制限となります。
(まあ、そこはメインプロジェクト開発者がUnitTestちゃんと
 書くようにすることで問題にならないようにできるかと)
ただ、公式ドキュメントのやり方とちょっと変わるので、
開発者にはしっかりその旨伝えておくべきです。

また、上記のExampleだとストアドのクラスは既に
mysqlプロジェクトで生成しているので、clientsqlプロジェクトでは
生成しないように設定していますが、DBFluteプロジェクトでは
Sql2Entityを実行しない方式であれば、(もしストアドが必要なら)
clientsqlプロジェクトに生成するようにして下さい。

上記は、一例として参考にして下さい。
DBFluteとしてもきっちりサポートしているわけではないので、
仕組みを良く理解してプロジェクトに合う形を探って
利用するようにして下さい。

#
# 個人的には、よっぼどの状況じゃない限りはお奨めしません。
# よっぼどというのは、
#    o メインプロジェクトが10個くらいあって開発者も30人超える
#    o メインプロジェクトの実装だけ(距離の遠い)別会社
# というような感じです。
# そうでなければ、DBFluteプロジェクトで複数人が同時Sql2Entityしても
# 大抵はSVNの(自動 or 手動)マージ機能で解消できるかと思います。
# (全部外だしSQLなら別ですがDBFluteにはConditionBeanがあるので、
#  SVNの運用さえきっちりしていればそんなに同時問題が発生しないかと)
#
# ただまあ、DBFlute.NETのCBはまだちょっとJavaのCBに比べて
# 機能不足な点が多いのでスコープの感覚がちょっと違いますね。
# (申し訳ないです)
#

2009/6/5 kubo <[E-MAIL ADDRESS DELETED]>:
> 久保(jflute)です。
>
>> BehaviorQueryPath(SQLファイルへのタイプセーフなパス定義)
>> が生成されないのが制限(のはず)です。
> 生成されない、ではなく、例外で落ちますね。
> 「該当のBehaviorが存在しません」という内容で。
> これは正常な動きで、チェックのために必要な例外です。
>
> 先述のBehaviorQueryPathの定義クラスを
> (つじつまがあるように)作成するか、もしくは、
> SQLファイルをBehaviorQueryPathの規約じゃない
> 場所・名前で作成して、Sql2EntityではEntityとPmbだけ
> 生成して、Pathは独自に解決するか、
> というのが現状かもしれません。
>
> 2009/6/5 kubo <[E-MAIL ADDRESS DELETED]>:
>> 久保(jflute)です。
>>
>> 小林さん、こんばんは
>>
>>> DBFluteConfig とは何だろうと、調べてみようと思いましたが、
>> 別のプロパティでJavaですが、こちら参考にしてみて下さい。
>> http://d.hatena.ne.jp/jflute/20080507/1210156415
>>
>> あと、クライアントプロジェクトでSql2Entityをそのままやると、
>> BehaviorQueryPath(SQLファイルへのタイプセーフなパス定義)
>> が生成されないのが制限(のはず)です。
>> 但し、クライアントプロジェクトにBsBhvのフォルダを
>> DBFluteプロジェクトのものと同じように作成し、
>> BsXxxBhv.csというファイル名で中のクラスは全然別で
>> そのクラスのどこかに
>>        /*df:BehaviorQueryPathBegin*/
>>        /*df:BehaviorQueryPathEnd*/
>> と定義しておくと、この場所にBehaviorQueryPathが
>> 定義されるかもしれません。試してないので完全に理論値です。
>> (DBFluteは、SQLファイルに対応するBsBhvのファイルの
>>  BeginとEndに定義をぶち込んでいるだけなのです)
>>
>> もともと想定された構成じゃないのでちょっと何が起こるか
>> わからないので、実際に試してみて下さい。
>>
>> 2009/6/5 小林貴生 <[E-MAIL ADDRESS DELETED]>:
>>> いつもお世話になっております。
>>> 以前も質問させて頂いた小林と申します。
>>>
>>>
>>> 今回も質問がありまして、メールさせて頂きました。
>>> 毎回毎回すいません。
>>>
>>>
>>> 今、DBFlute で自動作成したDLLを参照して、
>>> メインのプロジェクトでは、外だしSQLを書きたいと思っています。
>>>
>>> 調べている最中で、jflute のブログを拝見させて頂き、
>>>
>>>> (完全に正確かどうかは不明ですが...)
>>>>
>>>> o DBFluteプロジェクト (ライブラリプロジェクト)
>>>> o WEB1プロジェクト (メインプロジェクト)
>>>> o WEB2プロジェクト (メインプロジェクト)
>>>> o BATCHプロジェクト (メインプロジェクト)
>>>>
>>>> という構成で、
>>>> それぞれのメインプロジェクトがライブラリプロジェクトである
>>>> DBFluteプロジェクトを参照しているとしてます(全てC#)。
>>>> で、SQLファイルはそれぞれのメインプロジェクトで
>>>> 自分たちに必要なものだけを作成し、Sql2Entityして、
>>>> CustomizeEntityとPmbをメインプロジェクトに配置します。
>>>> それぞれメインプロジェクトの起動処理で、DBFluteConfigの
>>>> AdditionalAssemblyProviderで自分自身のAssemblyを指定。
>>>> とりあえずこれで、SQLファイルのメインプロジェクト管理を実現。
>>>
>>> の様に書いてあったので、実際にそれをしてみようと思いました。
>>>
>>>
>>> ．．．が、力不足のためよく分からず。
>>> 「DBFluteConfigのAdditionalAssemblyProviderで自分自身のAssemblyを指定」
>>> の部分で早々に詰まってしまいました。
>>>
>>> DBFluteConfig とは何だろうと、調べてみようと思いましたが、
>>> Example でも明示的に使われているところは無く（もしあったらごめんなさい。）、
>>> どのように設定するのが良いのか結局分かりませんでした。
>>>
>>>
>>> 実際に設定しているサンプルプログラム等をご存じの方はいらっしゃらないでしょうか。
>>> やはり、外だしSQLはDLLの中ではなくて、クライアントプロジェクトで書きたいのです。
>>>
>>> ．．．すいません、調べ方が悪いだけかも知れません．．．。
>>>
>>>
>>>
>>> 以上、よろしくお願いいたします。
>>>
>>>
>>> 小林貴生
>>>
>>> _______________________________________________
>>> seasar-dotnet mailing list
>>> [E-MAIL ADDRESS DELETED]
>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>>
>