Всё классно, спасибо! Но внедрение новых аббревиатур зашло не очень. Т.к. читал по диагонали то не сразу увидел дисклеймер про "sls" и немного залип, догадываясь откуда это. В любом случае, материал интересный!
Нужно ли выполнять синхронизацию автоматически это тот вопрос, который вы должны решить для себя самостоятельно. В данной статье речь идет в первую о том, чтобы формировать автоматически файлы миграций. Но что делать с этим файлом дальше — выполнять ли инспекцию, накат на тестовое окружение с дальнейшими тестами, каждый решает сам.
Кстати, справедливости ради скажу, что в pgCodeKeeper есть опция --safe-mode, которая запрещает генерацию SQL выражений, которые могут модифицировать данные. Т.е. для автоматического деплоя можно использовать кипер с данной опцией.
Вполне возможно, если возможностей этого инструмента достаточно, то почему бы и нет? Я, к сожалению, с ним раньше не работал, а при попытке запустить в докер контейнере (так описано на сайте Squitch) выходит ошибка:
[ags@home:~] $ docker run --rm docteurklein/sqitch:pgsql
/bin/sh: 1: [sqitch]: not found
По своему опыту могу сказать, что инструменты "заточенные" под работу под разные БД, показывают не всегда удовлетворительный результат при работе с особенностями конкретных вендоров БД.
Если Вы работали со Squitch, попробуйте повторить тот кейс, который описан в этой статье. Справится ли с ним Squitch? Какой скрипт миграции будет сформирован?
Да, такая версия существует на текущий момент. Надеюсь подготовить о работе консольной версии и интеграции её с Jenkins CI (для автоматического деплоя) одну из следующих статей.
> Непонятно, что имеется в виду. Изменения в п. 1 происходят вручную или через вашу программу?
Обычно п.1 выполняется разработчиком через pgAdmin или любой подобный инструмент. Но в некоторых (достаточно ограниченных случаях) проще внести изменения через pgCodeKeeper. В текущей итерации pgCodeKeeper инструмент в первую очередь для сопровождения, а не для разработки. Собственный редактор кода еще недостаточно хорош. Но с учетом того, что синтаксическое дерево у нас есть, то можно будет в будущем в этом направлении поработать. Но пока мы не рекомендуем pgCodeKeeper как (основной) редактор кода.
> В п. 2 предполагается, что данные БД находится отдельно, а код работы с БД под контролем версий? «Перенос в девелоперскую ветку» — это имеется в виду, что в программный код добавляется код миграции на новый формат хранения данных?
Кипер работает только с кодом. Под контролем версий находятся объекты БД — таблицы, представления, процедуры, типы, домены и др.
«Перенос в девелоперскую ветку» — это процесс синхронизации объектов БД с проектом. Из БД в ветку проекта. Используя следующую последовательность: Чтобы выполнить обновление проекта переключитесь на нижний таб “Обновить проект”, нажмите “Получить изменения”, выберите нужные объекты и нажмите на кнопку “Применить выбранные изменения”.
В последующем, подготовив мерж реквест (в терминах GitLab) для ветки связанной с боевой БД можно выполнить инспекцию измененных объектов.
Действительно, файлы помощи на текущий момент несколько устарели и на текущий момент обновляются. Но обратите внимание, что для старта вполне достаточно текущей статьи.
Перспектива в Eclispe определяет лишь расположение окон View, чтобы открыть окно редактора вызовите контекстное меню на проекте и выберите pgCodeKeeper — Открыть проект.
> Дампы же возвращают ошибку. Консоль, к слову, тоже не может в UTF-8
Вот эти два утверждения не совсем понятны. Все наши внутренние базы используют UTF-8 и каких-то проблем с использованием не обнаружено ни на Linux, ни на Windows. Попробуйте проверить свойства проекта (правой кнопкой мыши на проекте — Свойства), если вы его создавали на Windows, то возможно, что по умолчанию проект Eclipse был создан с кодировкой Windows-1251, если так, то измените проекту кодировку на UTF-8 и загрузите объекты в этот проект.
Как и Flyway так и Liquibase ничего не знают про особенности работы PostgreSQL, об этом собственно и была статья. По поводу продажи продукта, это утверждение спорно. На текущий момент нам интересна реакция сообщества на продукт. pgCodeKeeper это не тот продукт, на котором бы мы хотели строить бизнес. Возможно для корпоративных клиентов это и будет стоить какую-то денежку (поддержка пользователей, приоритезированное выполнение фич), но думаю, что для частного или академического использования использование будет свободным.
Ещё раз подчеркну, что на текущий момент модель лицензирования не выработана.
У Flyway и Liquibase есть свои ниши использования. Например БД сформированные при помощи Ruby ActiveRecord или Java Hibernate будут ими очень хорошо поддерживаться. В более сложных случаях возможны проблемы. И разработчики PostgreSQL об этом хорошо знают.
Всё классно, спасибо! Но внедрение новых аббревиатур зашло не очень. Т.к. читал по диагонали то не сразу увидел дисклеймер про "sls" и немного залип, догадываясь откуда это. В любом случае, материал интересный!
Нужно ли выполнять синхронизацию автоматически это тот вопрос, который вы должны решить для себя самостоятельно. В данной статье речь идет в первую о том, чтобы формировать автоматически файлы миграций. Но что делать с этим файлом дальше — выполнять ли инспекцию, накат на тестовое окружение с дальнейшими тестами, каждый решает сам.
Кстати, справедливости ради скажу, что в pgCodeKeeper есть опция --safe-mode, которая запрещает генерацию SQL выражений, которые могут модифицировать данные. Т.е. для автоматического деплоя можно использовать кипер с данной опцией.
Вполне возможно, если возможностей этого инструмента достаточно, то почему бы и нет? Я, к сожалению, с ним раньше не работал, а при попытке запустить в докер контейнере (так описано на сайте Squitch) выходит ошибка:
По своему опыту могу сказать, что инструменты "заточенные" под работу под разные БД, показывают не всегда удовлетворительный результат при работе с особенностями конкретных вендоров БД.
Если Вы работали со Squitch, попробуйте повторить тот кейс, который описан в этой статье. Справится ли с ним Squitch? Какой скрипт миграции будет сформирован?
Обычно п.1 выполняется разработчиком через pgAdmin или любой подобный инструмент. Но в некоторых (достаточно ограниченных случаях) проще внести изменения через pgCodeKeeper. В текущей итерации pgCodeKeeper инструмент в первую очередь для сопровождения, а не для разработки. Собственный редактор кода еще недостаточно хорош. Но с учетом того, что синтаксическое дерево у нас есть, то можно будет в будущем в этом направлении поработать. Но пока мы не рекомендуем pgCodeKeeper как (основной) редактор кода.
> В п. 2 предполагается, что данные БД находится отдельно, а код работы с БД под контролем версий? «Перенос в девелоперскую ветку» — это имеется в виду, что в программный код добавляется код миграции на новый формат хранения данных?
Кипер работает только с кодом. Под контролем версий находятся объекты БД — таблицы, представления, процедуры, типы, домены и др.
«Перенос в девелоперскую ветку» — это процесс синхронизации объектов БД с проектом. Из БД в ветку проекта. Используя следующую последовательность: Чтобы выполнить обновление проекта переключитесь на нижний таб “Обновить проект”, нажмите “Получить изменения”, выберите нужные объекты и нажмите на кнопку “Применить выбранные изменения”.
В последующем, подготовив мерж реквест (в терминах GitLab) для ветки связанной с боевой БД можно выполнить инспекцию измененных объектов.
Перспектива в Eclispe определяет лишь расположение окон View, чтобы открыть окно редактора вызовите контекстное меню на проекте и выберите pgCodeKeeper — Открыть проект.
Вот эти два утверждения не совсем понятны. Все наши внутренние базы используют UTF-8 и каких-то проблем с использованием не обнаружено ни на Linux, ни на Windows. Попробуйте проверить свойства проекта (правой кнопкой мыши на проекте — Свойства), если вы его создавали на Windows, то возможно, что по умолчанию проект Eclipse был создан с кодировкой Windows-1251, если так, то измените проекту кодировку на UTF-8 и загрузите объекты в этот проект.
Ещё раз подчеркну, что на текущий момент модель лицензирования не выработана.
У Flyway и Liquibase есть свои ниши использования. Например БД сформированные при помощи Ruby ActiveRecord или Java Hibernate будут ими очень хорошо поддерживаться. В более сложных случаях возможны проблемы. И разработчики PostgreSQL об этом хорошо знают.