Comments 19
Очень интересная разработка, спасибо. Сейчас я, к сожалению, не работаю с PostgreSQL; но при случае обязательно попробую.
Ну вообще ребят я не понял чем ваша штука лучше flyway. Вот если бы ей можно было генерить миграции для него поди было бы интереснее. Diff конечно хорошо, но то что diff не умеет сам распознавать сокращенное описание эт плохо. Дополнительно я так понял вы хотите это продавать за деньги, вот я как потенциальный покупатель могу сказать, что не купил бы :)
Как и Flyway так и Liquibase ничего не знают про особенности работы PostgreSQL, об этом собственно и была статья. По поводу продажи продукта, это утверждение спорно. На текущий момент нам интересна реакция сообщества на продукт. pgCodeKeeper это не тот продукт, на котором бы мы хотели строить бизнес. Возможно для корпоративных клиентов это и будет стоить какую-то денежку (поддержка пользователей, приоритезированное выполнение фич), но думаю, что для частного или академического использования использование будет свободным.
Ещё раз подчеркну, что на текущий момент модель лицензирования не выработана.
У Flyway и Liquibase есть свои ниши использования. Например БД сформированные при помощи Ruby ActiveRecord или Java Hibernate будут ими очень хорошо поддерживаться. В более сложных случаях возможны проблемы. И разработчики PostgreSQL об этом хорошо знают.
Ещё раз подчеркну, что на текущий момент модель лицензирования не выработана.
У Flyway и Liquibase есть свои ниши использования. Например БД сформированные при помощи Ruby ActiveRecord или Java Hibernate будут ими очень хорошо поддерживаться. В более сложных случаях возможны проблемы. И разработчики PostgreSQL об этом хорошо знают.
Как и Flyway так и Liquibase ничего не знают про особенности работы PostgreSQL, об этом собственно и была статья.
На стадии применения выдаст ошибку :)
По поводу продажи продукта, это утверждение спорно. На текущий момент нам интересна реакция сообщества на продукт.
Ну мне вот пока не понятны фичи. Что вот мне даст использование этой штуки? Это инструмент для создания миграций так? Ну вот я бы хотел чтобы инструмент давал выхлоп в систему миграции какую-нибудь. Это стразу дает большой плюс. Плюс неплохо иметь интеграцию с ней. К примеру взял я flyway миграции скормил их в pgCodeKeeper получил возможность смотреть что поменялось. Ну и дальше мог бы ее наращивать.
А программа может в Postgres 9.4 в utf-8? У меня, к примеру, база, созданная
/bin/initdb.exe -D e:/dbdata --no-locale -E UTF-8 просто не всасывается. Показывает пустую схему public и ни на кого не ругается. Дампы же возвращают ошибку. Консоль, к слову, тоже не может в UTF-8, а стоило бы.> Дампы же возвращают ошибку. Консоль, к слову, тоже не может в UTF-8
Вот эти два утверждения не совсем понятны. Все наши внутренние базы используют UTF-8 и каких-то проблем с использованием не обнаружено ни на Linux, ни на Windows. Попробуйте проверить свойства проекта (правой кнопкой мыши на проекте — Свойства), если вы его создавали на Windows, то возможно, что по умолчанию проект Eclipse был создан с кодировкой Windows-1251, если так, то измените проекту кодировку на UTF-8 и загрузите объекты в этот проект.
Вот эти два утверждения не совсем понятны. Все наши внутренние базы используют UTF-8 и каких-то проблем с использованием не обнаружено ни на Linux, ни на Windows. Попробуйте проверить свойства проекта (правой кнопкой мыши на проекте — Свойства), если вы его создавали на Windows, то возможно, что по умолчанию проект Eclipse был создан с кодировкой Windows-1251, если так, то измените проекту кодировку на UTF-8 и загрузите объекты в этот проект.
Давайте с простого. Инструкция на pgcodekeeper.ru/index.jsp либо устарела, либо просто неверна. Ссылки точно битые.
Когда создавал подключение, прописал базу данных postgres. Проект всё молчаливо втянул, но не смог отобразить ничего, кроме объявления схемы. У меня такое было, когда базу 9.4 пытались втянуть pgAdmin'ом от 9.3. Потому и поставил вопрос таким образом.
Попытки выполнить дампы так же не увенчались успехом. Выполнение pg_dump возвращало текст в UTF-8, которые предсказуемо обратился в кракозябры, отсюда и возмущение по поводу консоли. Я понимаю, стандартный элемент управления, командная строка, все дела, но мне это как-то ровно, я хочу розовую пони.
Я поменял в свойствах кодировку, закрыл приложение, открыл — и все окна diff'ов и прочего исчезли. У меня нет опыта работы с эклипс, но переход на перспективу «pgCodeKeper» не дал никаких результатов. Как и поиск нужного окна из списка. Кстати, кипера нету и в глобальных свойствах эклипса. Совпадение?..
В общем, постгресу, как и многим другим СУБД, не хватает таких же удобных инструментов, которые есть для шарпов и яв, но ваш конкретно сейчас я бы даже бета-версией назвать постеснялся, а тем более в реестр добавлять. Для вас это просто строчка, а кому-то придётся потратить не один тюбик нервов.
Когда создавал подключение, прописал базу данных postgres. Проект всё молчаливо втянул, но не смог отобразить ничего, кроме объявления схемы. У меня такое было, когда базу 9.4 пытались втянуть pgAdmin'ом от 9.3. Потому и поставил вопрос таким образом.
Попытки выполнить дампы так же не увенчались успехом. Выполнение pg_dump возвращало текст в UTF-8, которые предсказуемо обратился в кракозябры, отсюда и возмущение по поводу консоли. Я понимаю, стандартный элемент управления, командная строка, все дела, но мне это как-то ровно, я хочу розовую пони.
Я поменял в свойствах кодировку, закрыл приложение, открыл — и все окна diff'ов и прочего исчезли. У меня нет опыта работы с эклипс, но переход на перспективу «pgCodeKeper» не дал никаких результатов. Как и поиск нужного окна из списка. Кстати, кипера нету и в глобальных свойствах эклипса. Совпадение?..
В общем, постгресу, как и многим другим СУБД, не хватает таких же удобных инструментов, которые есть для шарпов и яв, но ваш конкретно сейчас я бы даже бета-версией назвать постеснялся, а тем более в реестр добавлять. Для вас это просто строчка, а кому-то придётся потратить не один тюбик нервов.
Действительно, файлы помощи на текущий момент несколько устарели и на текущий момент обновляются. Но обратите внимание, что для старта вполне достаточно текущей статьи.
Перспектива в Eclispe определяет лишь расположение окон View, чтобы открыть окно редактора вызовите контекстное меню на проекте и выберите pgCodeKeeper — Открыть проект.
Перспектива в Eclispe определяет лишь расположение окон View, чтобы открыть окно редактора вызовите контекстное меню на проекте и выберите pgCodeKeeper — Открыть проект.
Так, ладно, всё запустилось. Если быть точнее, я ХЗ что произошло, пока не перезапустил комп, база открывалось пустой, а эклипс не подтягивал ваш плагин в окна свойств и контекстные меню. Серьёзно. Я не знаю, что это было за колдунство, ваш продукт был не при чём. И я уже поискал распятие-кувалду на али.
Короче, был неправ. Иду дальше разбираться с инструментом.
Короче, был неправ. Иду дальше разбираться с инструментом.
> 1. Разработчик вносит изменения в девелоперскую БД
> 2. Изменения, внесенные разработчиком при помощи pgCodeKeeper, переносятся в девелоперскую ветку
Непонятно, что имеется в виду. Изменения в п. 1 происходят вручную или через вашу программу?
В п. 2 предполагается, что данные БД находится отдельно, а код работы с БД под контролем версий? «Перенос в девелоперскую ветку» — это имеется в виду, что в программный код добавляется код миграции на новый формат хранения данных?
> 2. Изменения, внесенные разработчиком при помощи pgCodeKeeper, переносятся в девелоперскую ветку
Непонятно, что имеется в виду. Изменения в п. 1 происходят вручную или через вашу программу?
В п. 2 предполагается, что данные БД находится отдельно, а код работы с БД под контролем версий? «Перенос в девелоперскую ветку» — это имеется в виду, что в программный код добавляется код миграции на новый формат хранения данных?
> Непонятно, что имеется в виду. Изменения в п. 1 происходят вручную или через вашу программу?
Обычно п.1 выполняется разработчиком через pgAdmin или любой подобный инструмент. Но в некоторых (достаточно ограниченных случаях) проще внести изменения через pgCodeKeeper. В текущей итерации pgCodeKeeper инструмент в первую очередь для сопровождения, а не для разработки. Собственный редактор кода еще недостаточно хорош. Но с учетом того, что синтаксическое дерево у нас есть, то можно будет в будущем в этом направлении поработать. Но пока мы не рекомендуем pgCodeKeeper как (основной) редактор кода.
> В п. 2 предполагается, что данные БД находится отдельно, а код работы с БД под контролем версий? «Перенос в девелоперскую ветку» — это имеется в виду, что в программный код добавляется код миграции на новый формат хранения данных?
Кипер работает только с кодом. Под контролем версий находятся объекты БД — таблицы, представления, процедуры, типы, домены и др.
«Перенос в девелоперскую ветку» — это процесс синхронизации объектов БД с проектом. Из БД в ветку проекта. Используя следующую последовательность: Чтобы выполнить обновление проекта переключитесь на нижний таб “Обновить проект”, нажмите “Получить изменения”, выберите нужные объекты и нажмите на кнопку “Применить выбранные изменения”.
В последующем, подготовив мерж реквест (в терминах GitLab) для ветки связанной с боевой БД можно выполнить инспекцию измененных объектов.
Обычно п.1 выполняется разработчиком через pgAdmin или любой подобный инструмент. Но в некоторых (достаточно ограниченных случаях) проще внести изменения через pgCodeKeeper. В текущей итерации pgCodeKeeper инструмент в первую очередь для сопровождения, а не для разработки. Собственный редактор кода еще недостаточно хорош. Но с учетом того, что синтаксическое дерево у нас есть, то можно будет в будущем в этом направлении поработать. Но пока мы не рекомендуем pgCodeKeeper как (основной) редактор кода.
> В п. 2 предполагается, что данные БД находится отдельно, а код работы с БД под контролем версий? «Перенос в девелоперскую ветку» — это имеется в виду, что в программный код добавляется код миграции на новый формат хранения данных?
Кипер работает только с кодом. Под контролем версий находятся объекты БД — таблицы, представления, процедуры, типы, домены и др.
«Перенос в девелоперскую ветку» — это процесс синхронизации объектов БД с проектом. Из БД в ветку проекта. Используя следующую последовательность: Чтобы выполнить обновление проекта переключитесь на нижний таб “Обновить проект”, нажмите “Получить изменения”, выберите нужные объекты и нажмите на кнопку “Применить выбранные изменения”.
В последующем, подготовив мерж реквест (в терминах GitLab) для ветки связанной с боевой БД можно выполнить инспекцию измененных объектов.
Планируется ли консольная версия, для работы в скриптах?
Да, такая версия существует на текущий момент. Надеюсь подготовить о работе консольной версии и интеграции её с Jenkins CI (для автоматического деплоя) одну из следующих статей.
мне думается, тут лучше подойдут другие средства миграции. типа Sqitch.
Вполне возможно, если возможностей этого инструмента достаточно, то почему бы и нет? Я, к сожалению, с ним раньше не работал, а при попытке запустить в докер контейнере (так описано на сайте Squitch) выходит ошибка:
[ags@home:~] $ docker run --rm docteurklein/sqitch:pgsql
/bin/sh: 1: [sqitch]: not foundПо своему опыту могу сказать, что инструменты "заточенные" под работу под разные БД, показывают не всегда удовлетворительный результат при работе с особенностями конкретных вендоров БД.
Если Вы работали со Squitch, попробуйте повторить тот кейс, который описан в этой статье. Справится ли с ним Squitch? Какой скрипт миграции будет сформирован?
Нет-нет, Sqitch не является заменой pgCodeKeeper, более того, мне кажется, что ваш инструмент удобно использовать для написания миграций такого рода (чтобы далее впиливать оные в план Sqitch).
Но вот когда речь идет о консоли, я уже не вижу смысла. Создать миграцию визуальным инструментом, после этого сохранить в план миграций Sqitch, и далее раскатывать им.
Отлично, это то, чего не хватает. Спасибо.
Sign up to leave a comment.
Приручение строптивого