@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に書いていこうと思います。 とりあえず今日はこんなところで。 なんにせよ悔いがないように頑張っていきたいと思います。
