2016-04-12 6 views
0

私はデータベースのMSSQLとOracleの実装をサポートするためにLiquibaseを使用しています。データベースはすでに存在します。Liquibaseにコレートのサポートを追加する

テーブル列に照合をサポートしたいと考えています。例:

<createTable tableName="my_table"> 
    <column autoIncrement="true" name="id" type="int"> 
    <constraints nullable="false"/> 
    </column> 
    <column name="name" type="varchar(50)"/> 
    <ext:column name="description" type="varchar(250)" collate="Latin1_General_CS_AS"/> 
</createTable> 

私はMSSQLの新しい属性を最初に処理したいだけです。私はmodifySqlタグが拡張子を使わずにcollateをサポートする手段を提供しているのを見ました。私は他の同様の変更もしたいと思うし、Liquibaseを拡張する考えを好む。

私は他の拡張機能を見てきましたが、既存のステートメントをうまく拡張する方法の例は見つかりません。私は以下を行うことを考えています:CreateTableChangeCreateTableStatementおよびCreateTableGeneratorコアを拡張するクラスCreateTableChange,CreateTableStatementおよびCreateTableGeneratorを書き込むカスタム を書くことを考えています。 generateStatementsメソッドをCreateTableChangeに置き換えて、カスタムCreateTableStatementインスタンスを作成し、generateSqlCreateTableGeneratorに置き換えてください。

これが既存の変更クラスを拡張する正しい方法かどうかを知りたいと思います。 generateStatementsgenerateSqlの基本実装を呼び出すことはできませんが、実装をコピーして貼り付けて、既存の拡張の代わりに新しい変更タイプのように見えるようにしなければならないと心配です。

答えて

0

私はliquibaseの拡張機能をまだ書いていないので、これは良いアプローチかより良い方法があるかどうかは分かりません。

しかし、私が気づいたのは、liquibase.changeliquibase.change.coreという2つのパッケージがあることです。最初のパッケージでは、抽象クラスとインタフェースはAbstractChangeのようです。エクステンションを書くときにあなたが実装し、拡張するはずのものだと思います。したがって、私はそのパッケージを拡張のためのAPIの一部とみなし、かなり安定していると考えています。

2番目のパッケージには、liquibaseが使用するクラスが含まれています。将来のバージョンで変更される可能性があります。 これらのクラスを拡張すると、拡張が頻繁に変更される可能性があります。私はそれらのクラスは "拡張API"の一部ではないと推測します。 (これを証明する正式な文書は見つかりませんでした。それは私の所見です)。

私はあなたのアプローチが実行可能でなければならないと言っています。

関連する問題