2009年の始まり

@DBFlute
いきなりリリースの0.8.8、これを安定板にしたいと考えています。
バグフィックスや微調整な修正は「0.8.8.x」としてリリースします。
少々重たい修正をした場合は、「0.8.9」とすることもあります。


「0.9.0」にて1.0前の最後の大きな修正をさせて下さい。
二つあります：

　A. Java版とC#版でバージョン運用の分離
　B. Java版allcommonパッケージのJARファイル化

＜A＞
Java版とC#版は完成度に違いがあります。
同じように作業があるときはよいのですが、
今後は「C#版だけ修正がある」というようなことも考えられます。
そのとき、Java版は変わらないのにバージョンが上がってしまうと
Java版ユーザにとってはやりづらい状況でしょう。また、逆に
Java版の修正が見つかるまでC#版がリリースされないのは
C#版ユーザにとってやりづらい状況でしょう。
今までメンテナンスコストを優先して一緒にしていましたが、
そろそろ分離管理する時期かなと考えました。
「1.0」の時期がJava版とC#版とで違う可能性もあります。

＜B＞
Java版だけの話ではあります。
現状は、BehaviorやEntityと共にフレームワークも自動生成しています。
フレームワークというのはallcommonパッケージがまさにそれです。

メリット：
　・デバッグ作業がしやすい
　・仕組みの理解に役に立つ
　・依存ライブラリが少なくシンプル

デメリット：
　・コンパイルスピードの劣化
　・mydbfluteのSVNコミット・更新が遅い
　・パッケージエクスプローラでバァァッ
　・複数DB構成時に別パッケージ同名クラス名がたくさん
　・フレームワーク内部のメンテコストが高い

今まではメリットを重視しておりましたが、
「1.0」に向けて、DBFluteがさらなる発展を遂げるために
これだけはやらないと、今がやるタイミングであると。
s2dao.jarがdbflute-framework.jar(未定)に差し換わる感じです。
移行は、「JARファイルの追加」と「Eclipseでの一括インポートの編成」
だけで可能になるようにしたいと思います。
(但しクラス名にPrefixを付ける機能を使っている場合はその限りではない)


ドキュメントの整備を行います。
英語のドキュメントも視野に入れて、基盤を整備する予定です。
あらかじめドキュメント内容の設計をし、複数人で作業できる
ような形にしたいと考えております。
ひとまず「DBFluteの提供するサービス」という視点で
その中で「全体最適化」のものを洗い出しています。
...書くことたくさんありますね。頑張ります。

[Total Optimization]

o テーブルのクラスを自動生成する
o 外だしSQLのクラスを自動生成する
o スキーマを作成してテストデータを登録する
o 外だしSQLを一括テストする
o スキーマ情報を眺望する
o 共通カラムを自動設定する
o 区分値をタイプセーフ解決する
o FK制約のない関連テーブルを関連付ける
o 業務的にone-to-oneのテーブルを関連付ける
o 排他制御(楽観的平行性制御)が行われるようにする
o デバッグしやすいログを出力するようにする
o 発行されたSQLを記録する
o 別名(和名)を定義する
o 自動生成時にEclipseを自動更新する
o Viewのクラスを自動生成する
o 古いテーブルの不要なクラスを削除する


o ストアドプロシージャをアプリから呼び出す
o 複数スキーマで利用する
o 複数DBで利用する
o Synonym/Aliasのクラスを自動生成する
o 自動生成されたクラスのauthorを指定する
o 自動生成されたクラスにコピーライトを付与する
o テーブル名にスキーマ名を必ず付与する
o 自動生成時のマッピングの型を調整する


o PKのないテーブルにもInsertできるようする
o PK制約のないテーブルを更新可能にする
o 外だしSQLのファイルエンコーディングを指定する
o 外だしSQLのファイル配置先パッケージを指定する
o データベース依存のメソッドを生成する
...

その他色々考えています。まだここで語れるほど固まってないものです。
語れる時点でBlogに書いていこうと思います。
とりあえず今日はこんなところで。
なんにせよ悔いがないように頑張っていきたいと思います。

DBFlute-0.8.8 リリース

@DBFlute
DBFlute-0.8.8をリリースしました。
http://www.seasar.org/wiki/index.php?ChangeLog%2FDBFlute

C#版でもfixedConditionでバインド変数

@0.8.8
> (DBFLUTE-404){C#}:
> additionalForeignKeyのfixedConditionでバインド変数
http://d.hatena.ne.jp/jflute/20081201/1228126523
の機能をC#版でも利用できるようになりました。

DB設計をして開発者へ横展開する時点で、DBAもしくは実装リーダが
あらかじめfixedConditionの設定をしておくのが望まれます。
(DBAは業務的な制約のことはERDに必ず書いておきましょう)

「構造的にone-to-manyだが業務的にone-to-one」
という概念、実はあまり浸透されていないような気がします。
DB設計上やSQL上では普通に使ってはいますが、色々な技術者と
話した感じでは、統一された言葉での表現がないようです。
そこで
「それって構造的にone-to-manyだが業務的にone-to-oneってこと？」
と聞くと
「あーそうそうそうそういうこと」
という会話が多かったです。
しかし、そういう状態だと、デメリットがあって：
　o DBA(仕様策定者)から開発者へ意思が伝わりにくい
　o 開発者が勘違いする可能性が高い
明示的な制約ではないため、DB構造だけでは伝わらないという
ただでさえ「伝えづらい概念」であるにも関わらず、
上記のようなデメリットがあると、現場で非常に効率の悪い
「やりとり」が発生する可能性があります。

こういうものをDBFluteで明示的な機能としてサポートすることにより、
皆様の「会話のしやすい概念」になってくれればいいなぁと思っています。
他の機能でも結構そういう「思い」のものがあったりします。
「DBFluteを使うことで、DBアクセスのエッセンスが学べる」
っての目指したいですね。

ReplaceSchemaでエラー続行したDDLの結果

@0.8.8
> (DBFLUTE-399){Java/C#}:
> ReplaceSchemaでエラー続行したDDLの結果を最後のログで表示

ReplaceSchemaのプロセスは以下のようになります：

1. Drop/Create Tables
2. Register test data
3. Check or Arrange

で、「2」は一行でも登録に失敗すればReplaceSchema中断ですが、
「1」と「3(のArrange)」は続行します。
それは、CREATE OR REPLACEがサポートされていないオブジェクトの
DROP文などどうしても「最初の一回目は正当に落ちる」というのを
許容せざるを得なかったりします。(OracleのSequenceなど)

なので、DDLで実行に失敗したStatementはログで確認する必要が
ありますが、流れるログを見つめてるか、処理の最初の方のログを
スクロールして後で追っかけるかする必要があるのですが、
0.8.8からは最後のログで以下のようなログを表示し、
落ちたDDLの有無を確認することが可能です。

// 全てのDDLがうまくいったとき
# /* * * * * * * * * * * * * * * * * * *
# [Final Information]
# 
#   {Create Schema}
#   [Fired SQL] success=26 failure=0 (in 1 files)
#   
#   {Take Finally}
#   [Fired SQL] success=0 failure=0 (in 0 files)
# * * * * * * * * * */

// 一つ(以上)DDLが失敗したとき
# /* * * * * * * * * * * * * * * * * * *
# [Final Information] *Failure
# 
#   {Create Schema}
#   [Fired SQL] success=25 failure=1 (in 1 files)
#   
#   {Take Finally}
#   [Fired SQL] success=0 failure=0 (in 0 files)
# * * * * * * * * * */

DerivedReferrerでcountDistinct()

@0.8.8
> (DBFLUTE-392){Java/C#}:
> DerivedReferrerでcountDistinct()をサポート

DerivedReferrerのメソッド「max()/min()/sum()/avg()/count()」
に加えて「countDistinct()」を追加しました。
count()との違いは「種類数」を取得するという点です。

　count() → count(ABC)
　countDistinct() → count(distinct ABC)

dbflute-basic-exampleのConditionBeanPlatinumTestに
Exampleが追加されています。ぜひご覧になられて下さい。

cb.specify().derivedPurchaseList().countDistinct(new SubQuery<PurchaseCB>() {
    public void query(PurchaseCB subCB) {
        subCB.specify().columnProductId();
        subCB.query().setPaymentCompleteFlg_Equal_True();
    }
}, "PRODUCT_KIND_COUNT");

ScalarCondition!

@0.8.8
@Java
> (DBFLUTE-379){Java}
> 最大値レコードを検索(ScalarCondition)

http://d.hatena.ne.jp/jflute/20081222/1229936373
ならびに
http://d.hatena.ne.jp/jflute/20081224/1230052469
にて既に紹介がありました。

「最大値レコードを検索」とありますが、それだけでなく
「平均値以上のレコードを検索」と組み合わせ次第で色々可能です。

dbflute-basic-exampleのConditionBeanPlatinumTestに
Exampleが追加されています。ぜひご覧になられて下さい。

cb.query().scalar_Equal().max(new SubQuery<MemberCB>() {
    public void query(MemberCB subCB) {
        subCB.specify().columnMemberBirthday(); // *Point!
        subCB.query().setMemberStatusCode_Equal_Formalized();
    }
});