2016-04-12 14 views
0

Ich verwende Liquibase, um MSSQL- und Oracle-Implementierungen einer Datenbank zu unterstützen. Die Datenbanken sind bereits vorhanden.Hinzufügen von Collate-Unterstützung zu Liquibase

Ich möchte Collate auf Tabellenspalten unterstützen. zB:

<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> 

Ich möchte das neue Attribut für MSSQL nur anfänglich verarbeiten. Ich habe gesehen, dass das modifySql-Tag eine Möglichkeit bietet, collate zu unterstützen, ohne Erweiterungen zu verwenden. Ich möchte auch andere ähnliche Änderungen vornehmen und bevorzuge die Idee, Liquibase zu erweitern.

Ich habe andere Erweiterungen angeschaut und finde kein Beispiel dafür, wie man bestehende Anweisungen schön erweitert. Ich denke dabei Folgendes zu tun: Schreiben benutzerdefinierte CreateTableChange, CreateTableStatement und CreateTableGenerator Klassen, die den Kern CreateTableChange, CreateTableStatement und CreateTableGenerator erweitern. Ersetzen Sie die generateStatements Methode in CreateTableChange, um benutzerdefinierte CreateTableStatement Instanzen zu erstellen und generateSql in CreateTableGenerator zu ersetzen.

Ich möchte wissen, ob dies der richtige Ansatz für die Erweiterung vorhandener Änderungsklassen ist. Ich bin besorgt, dass ich nicht die Basis-Implementierungen von generateStatements und generateSql aufrufen kann, aber die Implementierung kopieren und einfügen muss, und es sieht aus wie ein neuer Änderungstyp und nicht wie eine Erweiterung eines bestehenden.

Antwort

0

Ich habe noch nicht viel Erfahrung im Schreiben von Erweiterungen für Liquibase, also kann ich Ihnen nicht wirklich sagen, ob dies ein guter Ansatz ist oder ob es einen besseren Weg gibt.

Aber was ich bemerkt habe, ist, dass es zwei Pakete gibt: liquibase.change und liquibase.change.core. Im ersten Paket sind abstrakte Klassen und Schnittstellen wie AbstractChange. Ich denke, das sind diejenigen, die Sie implementieren und erweitern sollten, wenn Sie Erweiterungen schreiben. Daher würde ich dieses Paket als Teil der API für Erweiterungen betrachten und somit ziemlich "stabil" sein.

Das zweite Paket enthält Klassen, die Liquibase selbst verwendet. Sie könnten (werden) in zukünftigen Versionen geändert werden. Wenn Sie also diese Klassen erweitern, muss sich Ihre Erweiterung möglicherweise öfter ändern. Ich würde vermuten, dass diese Klassen nicht Teil einer "Extensions-API" sind. (Ich habe keine offizielle Dokumentation gefunden, die das beweist - es ist nur meine Beobachtung.)

Ansonsten würde ich sagen, dass Ihr Ansatz machbar sein sollte.