Может ли Liquibase использовать несколько табличных пространств DB2?

В DB2 LUW это рекомендуется, чтобы таблицы, индексы и" длинные объекты "(т. е. большие объекты) размещались в отдельных табличных пространствах. В наших существующих сценариях SQL есть такие строки:

CREATE TABLE "APPLICATIONTABLE"(
    APPLICATIONID INTEGER NOT NULL,
    APPLICATIONNAME VARCHAR(30) NOT NULL
)IN USERSPACE1 INDEX IN USERSPACE2 LONG IN USERSPACE3;

В наборе изменений мы можем указать табличное пространство:

<createTable tableName="APPLICATIONTABLE" tablespace="${tablespace.data}">
    <column name="APPLICATIONID" type="NUMBER(4, 0)">
        <constraints nullable="false"/>
    </column>
    <column name="APPLICATIONNAME" type="VARCHAR(30)">
        <constraints nullable="false"/>
    </column>
</createTable>

Но, насколько я понимаю, это не несколько табличных пространств DB2. Есть какой-либо способ сделать это?


person Martin McCallion    schedule 29.01.2015    source источник


Ответы (2)


Вы можете использовать sql change, который в документе Liquibase описывается как:

Тег «sql» позволяет вам указать любой sql, который вы хотите. Это полезно для сложных изменений, которые не поддерживаются с помощью тегов автоматического рефакторинга Liquibase, а также для обхода ошибок и ограничений Liquibase. SQL, содержащийся в теге sql, может быть многострочным.

Это выглядит так (скопировано из документа Liquibase):

<changeSet author="liquibase-docs" id="sql-example">
    <sql dbms="h2, oracle"
            endDelimiter="\nGO"
            splitStatements="true"
            stripComments="true">insert into person (name) values ('Bob')
        <comment>What about Bob?</comment>
    </sql>
</changeSet>

РЕДАКТИРОВАТЬ:

Только что увидел другой вариант после прочтения этого ответа. Вы можете использовать тег modifySql. Возможно, оставьте информацию о табличном пространстве и просто добавьте ее вот так (непроверенный код - просто предложение):

<createTable tableName="APPLICATIONTABLE">
    <column name="APPLICATIONID" type="NUMBER(4, 0)">
        <constraints nullable="false"/>
    </column>
    <column name="APPLICATIONNAME" type="VARCHAR(30)">
        <constraints nullable="false"/>
    </column>
    <modifySql dbms="db2">
        <append value=" IN USERSPACE1 INDEX IN USERSPACE2 LONG IN USERSPACE3"/>
    </modifySql>
</createTable>
person Jens    schedule 30.01.2015
comment
Спасибо. Да, это пришло мне в голову. Но, как и в наших существующих скриптах, у нас есть предложения IN USERSPACE1 INDEX IN USERSPACE2 LONG IN USERSPACE3 для каждой создаваемой таблицы. Если мы используем тег <sql> при каждом создании, мы теряем множество преимуществ, которые дает Liquibase. - person Martin McCallion; 30.01.2015
comment
Да, я знаю, что это не оптимальное решение. Просто хотел упомянуть об этом как о возможном обходном пути. - person Jens; 30.01.2015
comment
Другой вариант - использовать механизм расширения Liquibase и самостоятельно добавить недостающие функции - также не оптимально, потому что это может быть слишком интенсивно, но это вариант, который стоит рассмотреть ... Вы можете проверить уже существующий Oracle Extension или Postgres Extension в качестве примера ... - person Jens; 30.01.2015
comment
Да, думаю, мне придется это сделать. Или на самом деле просто внесите изменения в ядро. Это то, что может быть у DB2, поэтому в идеале это должно быть в поддержке DB2. - person Martin McCallion; 31.01.2015
comment
Ву! только что видел вашу правку. Я собираюсь попробовать это прямо сейчас. Спасибо. - person Martin McCallion; 02.02.2015
comment
Почти, почти ... это работает так, как мне хотелось бы, пока у меня не будет набора изменений с атрибутом примечаний. Это генерирует предложение COMMENT ON как часть CREATE TABLE, а после этого появляется дополнительный INDEX IN USERSPACE2..., что является синтаксической ошибкой. - person Martin McCallion; 02.02.2015
comment
Что ж, может быть, вы также можете опустить тег примечаний и добавить его в конец, используя modifySql? - person Jens; 02.02.2015
comment
Спасибо. Снова хорошие мысли. Однако оказалось, что (как я сначала подумал) COMMENT ON... - это отдельный оператор SQL. Liquibase добавляет содержимое <modifySql> после этого оператора, а также после CREATE TABLE. Я думаю, что это ошибка Liquibase, и постараюсь ее исправить. Проблема в том, что это неоднозначно: тег <modifySql> находится внутри <changeSet>, а не только внутри <createTable>. - person Martin McCallion; 03.02.2015
comment
Замечу, что об этой проблеме уже сообщалось: CORE-2190. - person Martin McCallion; 03.02.2015
comment
Я прокомментировал CORE-2190 после просмотра источников. modifySql должен быть общим, а не только модификатором для createTable. Однако есть проблема с Liquibase в том, как обрабатывается remarks. Вы уже разбирались в этом? Я запустил для него pull request. Хотя это не проверено и должно рассматриваться как предложение ... - person Jens; 05.02.2015
comment
Добавлю здесь комментарий для справок в будущем, хотя я также прокомментировал GitHub. У меня работает исправление Йенса (с небольшими изменениями). Теперь мне просто нужно решить, что мне нужно сделать, чтобы получить правильные настройки табличного пространства в операторах CREATE INDEX. - person Martin McCallion; 05.02.2015

Это то, что поддерживается расширениями Datical для Liquibase, но не в самом Liquibase.

person SteveDonie    schedule 29.01.2015
comment
Спасибо. Я забыл о Datical. Это стоит, не так ли? - person Martin McCallion; 29.01.2015
comment
Да, Datical действительно стоит денег. Отказ от ответственности: я работаю в Datical. Наши нынешние клиенты находят дополнительные функции, которые мы добавляем, которые стоят потраченных на них средств. - person SteveDonie; 31.01.2015
comment
Однако это заставляет меня задаться вопросом: если мы перейдем на использование Datical, потеряем ли мы преимущество использования приложения с открытым исходным кодом? В течение нескольких недель, когда я работал над добавлением наших скриптов в Liquibase, я внес несколько изменений в базу кода, чтобы исправить ошибки и расширить поддержку. Если бы мы использовали Datical, я бы ожидал, что это будет невозможно. Вместо этого нам придется подавать отчеты об ошибках и ждать исправлений. Или мы по-прежнему сможем вносить изменения в части с открытым исходным кодом? - person Martin McCallion; 31.01.2015
comment
Версия Liquibase с открытым исходным кодом является ядром Datical, и мы регулярно вносим обновления. Основной автор Liquibase (Натан Воксланд) сейчас работает на Datical на полную ставку, поэтому мы очень тесно сотрудничаем с ним и с сообществом. Когда я вношу изменения в Liquibase, я отправляю их через стандартный процесс запроса на вытягивание. Любые ваши изменения будут обрабатываться аналогичным образом. У вас может возникнуть дополнительное время обработки, но вы получите дополнительную стабильность, тестирование, функции, обучение, поддержку и т. Д., Которые предоставляет Datical. - person SteveDonie; 02.02.2015
comment
Извините за изменение принятого ответа. Ваш информативный и, без сомнения, был бы решением, но Jens's сейчас работает. - person Martin McCallion; 05.02.2015
comment
Не стоит беспокоиться. Я не занимаюсь S.O. для очков, я делаю это, чтобы помочь людям. - person SteveDonie; 05.02.2015