А в чем преимущество генерации SDK из SQL по сравнению с использованием ORM с поддержкой построения авто-миграций и генерации запросов?
Как обеспечить обратную совместимость в авто-миграции ORM? Это то, что необходимо для бесшовных релизов и Continuous Deployment. Они должны быть такими, чтобы одновременно могла работать и старая и новая версия приложения.
Миграции через ORM усложняют деплой, если вы разворачиваете несколько инстансов приложения. Какой инстанс должен накатывать миграции?
ORM вас приковывает к одному языку программирования в качестве клиента. Иначе получите хаос в зависимостях. Например: ORM в Java имплицитно определяет схему БД, клиент БД на Python эту схему должен либо выводить из кода Java, либо из развёрнутой БД. Менять схему будет сверхдорого.
ORM ограничивает вас до примитивных запросов. Для серьёзного использования возможностей БД нужен доступ к SQL.
ORM забирает на себя контроль за производительность запросов. В нетривиальных случаях, как правило, это сбоит.
Плюс как вы отслеживаете актуальность версии SDK: есть две команды, одна использует версию 1.0, вторая 1.1, выпускаете версию 1.2, в которой переименовываете табличку, а какой-то из клиентов все еще использует старое название?
Сперва маленькая ремарка: версию 1.2 с переименованием таблицы я бы скорее назвал 2.0, квалифицируя это как обратно-несовместимое изменение по SemVer.
Озвученная вами проблема решается теми же способами, как в REST-API переход с /v1 на /v2. Если это внутри компании, то все пользователи вам должны быть известны и можно решить коммуникацией. Дать срок на переход и дождаться отмашки, что ребята готовы. Выкатывать переименование таблички, пока есть важные системы, к этому не готовые, конечно, нельзя.
Этот процесс возможно и автоматизировать различными способами. Можно, например, ввести реестр актуально используемых версий SDK, заполнять его в CI на стороне клиентов. Но звучит как overkill.
Можно косвенно мониторить актуальное использование по статистике скачиваний артефактов из какого-нибудь artifactory. В компаниях, где идёт активная разработка, как правило, актуальные артефакты скачиваются множество раз в день.
Как вы сами заметили, процедура эта в некоторых случаях невозможна. Данные из удалённой таблицы откатом миграции не вернёшь. В чём тогда польза?
Я не вижу никакой, кроме способа для успокоения себя держать под рукой готовую миграцию, устраняющую последствия от накатываемой. Ну, если так уж сомневаетесь в конкретной миграции (настолько её не протестировали), держите такую миграцию наготове в MR/PR и замерджите и задеплойте через CD, если потребуется, как следующую миграцию. В большинстве же случаев вы сможете по факту написать необходимую миграцию, устраняющую последствия не многим медленнее.
Обременять разработку и автоматизацию необходимостью постоянно поддерживать обратный путь миграций, который, к тому же, мало кем полноценно тестируется, а применяется на деле практически никогда, кажется мне бессмысленным. Замечу, что я не один с таким мнением. Например, автор Postgraphile запилил альтернативный мигратор с такой же аргументацией.
Помимо сказанного замечу, что с проверками обратной совместимости, описанными в статье, вероятность наступления ситуаций, когда вам экстренно потребуется делать откат, снижается радикально.
Однозначно полезная практика: встраивать такого рода проверки в CI. Одноразовая инвестиция в настройку конвейера исключит спектр потенциальных проблем с расхождением данных. А за этим могут крыться как косвенные убытки вроде времени работников на устранение последствий, так и прямые в виде потерянных продаж с юридическими последствиями.
Насколько я знаю (довольно поверхностно), есть полукоммерческие инструменты в близком пространстве адресуемых проблем. Bytebase, например. Какое ваше мнение о них? Чем db_verifier отличается?
v1 в названии конфигурационного файла project.dbfirst-v1.yaml определяет версию его синтаксиса. В будущем это упростит инструменты для взаимодействия с синтаксисом (подсветку, редактор).
version: 1.0.0 внутри этого файла определяет версию пользовательского проекта. Это даёт пользователю определять версии генерируемых пакетов. В случае с Java, это определяет значение project/version в pom.xml.
v1 в java-jdbc-v1 определяет версию кодогенератора. Это обеспечивает обратную совместимость генерируемого SDK.
может версионирование как-то отделить от названия?
В будущем планируется добавить конфигурируемость различных деталей кодогенерации для кастомизации пользователем. Тогда данное строковое значение станет эквивалентом следующему словарю:
artifacts:
- java-jdbc:
version: 1
# Далее примеры дополнительных настроек, которые, возможно, будут внедрены в будущем:
min-jdk: 11
formatter: intellij
На будущее учту запрос на такой туториал. Было бы полезно, если бы вы конкретизировали, что именно в нём хотели бы увидеть.
В общих же словах, вы получаете декоратор над соединением JDBC, который реализует интеграцию со всеми запросами. Соединение с JDBC остаётся под вашим управлением, так что все стандартные практики должны быть применимы.
Программист, не знающий английского — это как менеджер, не умеющий Косынку раскладывать. Серьёзно. Как он будет функции называть? Как он будет понимать, как пользоваться сотнями библиотек, что неизбежно? Профессиональный мир общается исключительно на английском. И это всё помимо того, что перевод неизбежно коверкает оригинал.
Не нужен перевод. Не считаю, что на этом возможно заработать или принести этим какую-либо пользу.
Аналогичная проблема с прототипированием. Если базовый прототип на питоне появляется чуть ли не копипейстом того, что в интерактивной среде в лаборатории сделал, но в Хаскеле это обычно некое священнодействие, которое на некоторое время уходит самое в себя (типы и т. д.), и только через некоторое время приводит к результату. Если оказывается, что результат «не совсем то, о чём мечтали», то становится это понятно уже ближе к финалу, а не в начале. Таким образом, цена итерации в поиске решения увеличивается, делая весь процесс менее гибким.
Не допускаете ли Вы, что это может быть обусловлено лишь большей опытностью программистов в Питоне? Мне кажется, дело в том, что уровень виртуоза во владении Питоном требует куда меньших знаний и трудозатрат, чем Хаскелом. Поэтому Ваши программисты могли просто ещё не реализовать своего потенциала в Хаскел — отсюда и меньшая производительность.
От себя могу заметить, что, имея за плечами год ежедневной работы с Хаскел, уже ощущаю, что выполняю работу на уровне производительности, сравнимом с ООП языками из своего багажа. При этом я ощущаю и гигантский потенциал для роста своей производительности. Я осознаю, что до сих пор порой трачу время на моменты, когда в мозгу происходит «перещёлкивание» и, вдруг, я открываю для себя ещё что-то новое.
Это использование беспардонного бреда как аргумента.
Выводы о качестве не я делаю, а люди.
Чужие мысли читаете? Где эти люди с выводами? Хоть одна ссылка, может?
Я, к счастью, не являюсь обладателем. Почитайте отзывы на форумах соответствующих, том же 4PDA
Ах, да. Вы, должно быть, это считаете ссылкой. Только вот удостовериться в том, что Вашим предрассудкам на 4PDA есть хоть одно подтверждение, что-то запамятовали.
Я устал объяснять, не нравится мое объяснение, доебитесь до кого-нить еще
Сим же Вы, очевидно, исчерпав нелепые аргументы, подвели черту своему потоку высокомерного хамства.
Выходит, не держал, не видел, не читал, но «всё знаю»? Я ссылки на конкретные видеообзоры предоставил, где подтверждается всё, что угодно, но не Ваши умозаключения. С Вашей же стороны пока были только голословные доводы.
Спасибо за вопросы!
Как обеспечить обратную совместимость в авто-миграции ORM? Это то, что необходимо для бесшовных релизов и Continuous Deployment. Они должны быть такими, чтобы одновременно могла работать и старая и новая версия приложения.
Миграции через ORM усложняют деплой, если вы разворачиваете несколько инстансов приложения. Какой инстанс должен накатывать миграции?
ORM вас приковывает к одному языку программирования в качестве клиента. Иначе получите хаос в зависимостях. Например: ORM в Java имплицитно определяет схему БД, клиент БД на Python эту схему должен либо выводить из кода Java, либо из развёрнутой БД. Менять схему будет сверхдорого.
ORM ограничивает вас до примитивных запросов. Для серьёзного использования возможностей БД нужен доступ к SQL.
ORM забирает на себя контроль за производительность запросов. В нетривиальных случаях, как правило, это сбоит.
Сперва маленькая ремарка: версию
1.2с переименованием таблицы я бы скорее назвал2.0, квалифицируя это как обратно-несовместимое изменение по SemVer.Озвученная вами проблема решается теми же способами, как в REST-API переход с
/v1на/v2. Если это внутри компании, то все пользователи вам должны быть известны и можно решить коммуникацией. Дать срок на переход и дождаться отмашки, что ребята готовы. Выкатывать переименование таблички, пока есть важные системы, к этому не готовые, конечно, нельзя.Этот процесс возможно и автоматизировать различными способами. Можно, например, ввести реестр актуально используемых версий SDK, заполнять его в CI на стороне клиентов. Но звучит как overkill.
Можно косвенно мониторить актуальное использование по статистике скачиваний артефактов из какого-нибудь artifactory. В компаниях, где идёт активная разработка, как правило, актуальные артефакты скачиваются множество раз в день.
Спасибо за вопрос!
Как вы сами заметили, процедура эта в некоторых случаях невозможна. Данные из удалённой таблицы откатом миграции не вернёшь. В чём тогда польза?
Я не вижу никакой, кроме способа для успокоения себя держать под рукой готовую миграцию, устраняющую последствия от накатываемой. Ну, если так уж сомневаетесь в конкретной миграции (настолько её не протестировали), держите такую миграцию наготове в MR/PR и замерджите и задеплойте через CD, если потребуется, как следующую миграцию. В большинстве же случаев вы сможете по факту написать необходимую миграцию, устраняющую последствия не многим медленнее.
Обременять разработку и автоматизацию необходимостью постоянно поддерживать обратный путь миграций, который, к тому же, мало кем полноценно тестируется, а применяется на деле практически никогда, кажется мне бессмысленным. Замечу, что я не один с таким мнением. Например, автор Postgraphile запилил альтернативный мигратор с такой же аргументацией.
Помимо сказанного замечу, что с проверками обратной совместимости, описанными в статье, вероятность наступления ситуаций, когда вам экстренно потребуется делать откат, снижается радикально.
Однозначно полезная практика: встраивать такого рода проверки в CI. Одноразовая инвестиция в настройку конвейера исключит спектр потенциальных проблем с расхождением данных. А за этим могут крыться как косвенные убытки вроде времени работников на устранение последствий, так и прямые в виде потерянных продаж с юридическими последствиями.
Насколько я знаю (довольно поверхностно), есть полукоммерческие инструменты в близком пространстве адресуемых проблем. Bytebase, например. Какое ваше мнение о них? Чем db_verifier отличается?
Спасибо! Очень полезные уточняющие вопросы.
v1в названии конфигурационного файлаproject.dbfirst-v1.yamlопределяет версию его синтаксиса. В будущем это упростит инструменты для взаимодействия с синтаксисом (подсветку, редактор).version: 1.0.0внутри этого файла определяет версию пользовательского проекта. Это даёт пользователю определять версии генерируемых пакетов. В случае с Java, это определяет значениеproject/versionвpom.xml.v1вjava-jdbc-v1определяет версию кодогенератора. Это обеспечивает обратную совместимость генерируемого SDK.В будущем планируется добавить конфигурируемость различных деталей кодогенерации для кастомизации пользователем. Тогда данное строковое значение станет эквивалентом следующему словарю:
Спасибо. Примеры выложил в новой статье в виде туториала: https://habr.com/ru/articles/781550/
Опубликовал следующий пост в виде туториал с примером: https://habr.com/ru/articles/781550/
Пока, возможно, вам будет интересен вот этот пост.
Что подразумевается под "согласовать"? И почему хочется не писать запросы тривиальных выборок?
Спасибо за замечание! Однако пока кодогенератор не поддерживает этих типов. Но мы внесём это в планы.
На будущее учту запрос на такой туториал. Было бы полезно, если бы вы конкретизировали, что именно в нём хотели бы увидеть.
В общих же словах, вы получаете декоратор над соединением JDBC, который реализует интеграцию со всеми запросами. Соединение с JDBC остаётся под вашим управлением, так что все стандартные практики должны быть применимы.
Уместным ещё как найду! Спасибо за такую детальную и конструктивную обратную связь!
Спасибо! Я бы обе библиотеки отнёс к ORM. Они так же подходят к проблеме с помощью абстракций и относятся к SQL как к байткоду и прячут его.
Спасибо за конструктивный фидбек! Скоро дополним.
Не нужен перевод. Не считаю, что на этом возможно заработать или принести этим какую-либо пользу.
Не допускаете ли Вы, что это может быть обусловлено лишь большей опытностью программистов в Питоне? Мне кажется, дело в том, что уровень виртуоза во владении Питоном требует куда меньших знаний и трудозатрат, чем Хаскелом. Поэтому Ваши программисты могли просто ещё не реализовать своего потенциала в Хаскел — отсюда и меньшая производительность.
От себя могу заметить, что, имея за плечами год ежедневной работы с Хаскел, уже ощущаю, что выполняю работу на уровне производительности, сравнимом с ООП языками из своего багажа. При этом я ощущаю и гигантский потенциал для роста своей производительности. Я осознаю, что до сих пор порой трачу время на моменты, когда в мозгу происходит «перещёлкивание» и, вдруг, я открываю для себя ещё что-то новое.
Это использование беспардонного бреда как аргумента.
Чужие мысли читаете? Где эти люди с выводами? Хоть одна ссылка, может?
Ах, да. Вы, должно быть, это считаете ссылкой. Только вот удостовериться в том, что Вашим предрассудкам на 4PDA есть хоть одно подтверждение, что-то запамятовали.
Сим же Вы, очевидно, исчерпав нелепые аргументы, подвели черту своему потоку высокомерного хамства.
Хабр тут не при чём.
Говорите 4PDA смотреть? Ок. Вот на 4PDA о том как первая партия телефона распродаётся за 45 секунд. Вот тред с его обсуждением из 46 страниц. Но это всё, конечно же, потому что ажиотаж всегда формируется вокруг никому не нужной «китайщины». Хотя, что я говорю? Вы-то, конечно, лучше знаете. И Тайвань у нас вовсе не Китай, а Мерседес.