S2JDBCではエンティティ中心の開発（エンティティを正としてDB等がそれに倣う）を推奨している。 なので「エンティティ修正」→「コード生成」→「エンティティ修正」…と繰り返していくことになる。

gen-ddlはddlの変遷を独自に管理してくれて開発者がgen-ddlを実行する度にバージョンを切ってくれる。

これはエンティティの数が少ない場合や、エンティティを一人がまとめて管理しているとか開発人数が数人の場合はよいが、エンティティ数が多く、誰がどのエンティティを開発しているかわからない場合は使えない。

みんなが独自にエンティティを改造し、個別にgen-ddlしていくわけだから各自の変更がゴチャゴチャになってしまい足並みが揃わない。バージョン管理ツールでマージしたとしても各自の変更がその瞬間を表現しない。

そこで足並みをそろえてなんとかみんなで開発できるようにgen-ddlを改造してみる。

gen-ddlが勝手にバージョンを切るからコードを共有する際に問題になる。なのでこの管理をやめる。

最初にgen-ddlすると。0000と0001のバージョンが作られる。 この状態でmigrateすると…

• 0001のdropが全部実行
• 0001のcreateが実行

これはddl-info.txtが現在0001バージョンですよと指定しているからだ。 なのでgen-ddlをする度にddl-infoの内容がインクリメントされるのでまずコレを固定すればいい。

0001状態のddl-info.txtをddl-info-0001.txtとして保存。 そしてs2jdbc-gen-build.xmlのタスクに細工する。

gen-ddlのタスクの最後にantタスクでインクリメントされたddl-info.txtの削除と0001のddl-infoのコピータスクを書き加える。

<if>
  <available file="db/ddl-info-0001.txt" type="file" />
  <then>
    <copy file="db/ddl-info-0001.txt" tofile="db/ddl-info.txt" overwrite="true" />
  </then>
</if>

これで何度gen-ddlやってもddl-infoは常に0001バージョンを示すようになった。 つまりmigrateも常に0001を実行するようになる。

最初の1回考慮して存在チェック書いておこう

常に0001状態でgen-ddlするとバージョンが切られて0002が生成されるのでこれも0001に固定したい。

通常生成される0002は完璧な状態で生成される。 000xは0001にも0002にも他のどのバージョンにも依存しない形で生成される。

なのでそのままそっくり0001にリネームしてしまえばよい。 ddl-info.txtの時と同様にantタスクに削除とリネーム処理を入れ込む

<if>
  <available file="my_directory" type="dir" />
  <then>
    <echo message="Directory exists" />
  </then>
  <else>
    <echo message="Directory does not exist" />
  </else>
</if>

<if>
  <available file="db/migrate/0002" type="dir" />
  <then>
    <delete dir="db/migrate/0001"/>
    <move file="db/migrate/0002" tofile="db/migrate/0001"/>
  </then>

S2JDBC-Genで好都合のことは自動生成対象外のディレクトリやファイルは次のバージョンのディレクトリにも自動的にコピーされるということだ。

つまり0001バージョンで施した独自の改造(データベースのviewを生成するSQLとか)はそのまま0002に引き継がれる。 なので開発者は0001に対して変更し単にgen-ddlすればよい。

それぞれの開発者の変更の最終的なものが0001に全部マージされることになる。

こいつをコミットすればS2JDBCでバージョンを管理する必要は無い。全員が0001バージョンに変更点を書き加えたり、生成結果を0001に吐き出すのでpullした時に適宜マージすればいい

開発時のデータは開発者の使っているデータベース状態や開発状況に依存するので共有しても特別意味は無い。 開発者それぞれのデータのスナップショットなんて欲しくないのだ。

なので特に共有する理由も何もないのでデータのダンプをやめることにする。

<gen-ddl
      classpathdir="${classpathdir}"
      rootpackagename="${rootpackagename}"
      entitypackagename="${entitypackagename}"
      env="${env}"
      jdbcmanagername="${jdbcmanagername}"
      classpathref="classpath"
      autogenerateforeignkey="false"
      dump="false"
      templatefileprimarydir="templates">
        <jvmarg value="${vmarg.encoding}"/>
</gen-ddl>

このように

dump="false"

の設定を書き込んでデータのダンプを抑制する。

• 開発者Aがプロジェクトを作る
• 開発者Aがエンティティを作る
• 開発者Aがgen-ddlする
• 開発者Aがddl-info-0001.txtを設置
• 開発者Aがmigrate。開発者AのDBが0001エンティティに倣う
• 開発者Aがコミットしてプッシュ
• 開発者Bがプロジェクトをクローン
• 開発者Bがmigrate。開発者BのDBが0001エンティティに倣う
• 開発者Bがエンティティを作る
• 開発者Bがgen-ddlする(Aが作ったエンティティとBが作ったエンティティ関連のDDLが生成される)
• 開発者Bがmigrate。開発者BのDBが0001エンティティに倣う
• 開発者Bがコミットしてプッシュ
• 開発者Aがプル
• 開発者Aがmigrate。開発者AのDBが0001エンティティに倣う

運用としては、最初gen-ddlしてddl-info-001.txtを置いてあとはぐるぐる。

2012-08-25