FAQ

LiquiBase は、GNU Lesser General Public License (LGPL) のライセンスでリリースされています。

ソースコードは ダウンロード ページから入手可能です。

LiquiBase は、よりよく動きます。なぜなら変更が何かを 理解している からです。たとえば、データベースの比較プログラムが単純に、 結合環境の “person” テーブルに “firstname” と “lastname” カラムがあり、本番環境のシステムの、 “person” テーブルには、”name” カラムがあった場合、単純に “name” カラムをドロップして、 “firstname” カラムと “lastname” カラムを追加するようにレポートするでしょう。これはあなたのスキーマを適切な状況におくかもしれませんが、進行中は全員の名前(name)の値を失うことになります。LiquiBase を利用すれば、変更セットは、” 'name' カラムを 'lastname' にリネームして、'firstname' カラムを追加するようにレポートするでしょう。” またもっとよい場合には、”name カラムをスペースで分割して、'firstname' と 'lastname' カラムにわけ、次に 'name' カラムをドロップするようにレポートすることもあるでしょう。” なぜ それらが本番環境と異なっているかを理解することで、価値あるデータを失うおそれがないのです。

LiquiBase は分散されたロックシステムを利用して、同時に一つのプロセスだけがデータベースを更新できるようになっており、ほかのプロセスは単純にロックが解放されるまで待つことになります。

はい。それぞれの変更は独立しており、ことなるブランチで作成されてマージされたデータベースへの変更が LiquiBase から実行されるからです。文が実行される順序に関して問題が発生するかもしれませんが、変更ログファイルの順序を並び替えることでどんな問題でも容易に解決できるでしょう。

なぜ、”id” タグだけではだめなのでしょう? author と id 属性タグの両方を必要とする主な理由は、同一人物が同じ “id” の値を利用することが簡単に起こりうるからです – とくに複数のブランチを使用しているときには。ソース管理システムは、異なるブランチに追加された2つの変更セットを解決し、マージしようとしますが、2つの異なる変更セットが同じ “id” を利用することは気にしませんので、いったん変更セットがひとつの id でデータベースに対して実行されてしまうと、(かんたんには) 変更できません。 author タグに基づいて変更セットの一意性を決定することで、重複の可能性を低減させています。

組織によっては、変更を特定の個人にひもづけたくない場合や、もとの作者(author)が本当にわからない場合もあるでしょう。このときには、値を “UNKNOWN” のような値に変えてしまってください。