Вопрос разработчикам - а зачем вы так делаете ? Ответ - у нас фреймворк такой.
На мой взгляд - нормальный ответ. Если так сделано фреймворком, то, как минимум, стоит с такого начать. Если вопрос - к его разработчикам, но он задан не там, но полагаю, авторы нашли бы, что ответить.
И, раз позднее проблему решили, в ней не было ничего концептуального. Полагаю, до выхода в прод не нашлось причины переделать это место.
ирония, шутка, гротеск
Да ничего подобного. Если у вас при выходе в прод оказалось, что какая-то транзакция начала залипать, значит можно сформулировать тест на количество таких операций в секунду, который развалился бы и в момент приемки. И если бы этот тест был в ТЗ, вы бы избежали полугода боли. Точно ли тут виноват разработчик (а он компетентен, раз исправил в итоге) или, все-таки, ТЗ оказалось не вполне адекватным?
Про FOR UPDATE .. SKIP LOCKED, полагаю, отлично расписали в документации - "Skipping locked rows provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table". И да, пост depesz про эту фичу в свое время был как глоток свежего воздуха для тех, кто пилил очереди. Результат в проде 10+ лет, к слову.
pg_advisory_lock.. тут пишут - "There are two ways to acquire an advisory lock in PostgreSQL: at session level or at transaction level." Вы о каком? Тут бы не помешала конкретика, с 97го пару раз встречал кейсы, где это пригодилось (не считая, конечно, тех кейсов, которые разработчиков СУБД убедили эту фичу запилить)
PS. "при реальных пользователях нет" читается как "пока не научились писать адекватные тесты"
Проект, который писался лет 10 назад на perl и хранимых процедурах
…
Тогда привлекли сторонних разработчиков perl для аудита.
Как автор аналогичного проекта, впечатлен. Те, кто сейчас его поддерживают в проде, давненько на perl ничего не писали. И даже если в проекте есть "ад", искали бы его не в БД.
И да, это не про контроль версий или автотесты, там это все было сразу.
Вы сменили тему ветки, но поддержу) Я тоже считаю, что "потеря данных неприемлема", но, в моем случае, считаю это профессиональной деформацией. Да, в банке такой прокол легко измерим деньгами и виновного можно найти и выставить на зарплату всей его остальной жизни. Но вот в других сферах бизнеса я с изумлением наблюдал совершенно иное, в духе "ну ладно, перезальем эти файлы" или "что ж, в этом месяце подняли чуть меньше"… там топам даже искать виновного бывает лень. И тут я вполне допускаю, что какие-то потери ради некоторых плюсов (вроде не положить весь сервис на близком пике) могут быть и оправданы и априори приемлемы… Да, после пика можно бы вернуться к проблеме и все-таки эти данные восстановить. Но "не смогли" и "не захотели" — это разные варианты и оба они к теме текущей статьи, на мой взгляд, отношения не имеют.
Ваш пост о том, что вы отрицаете возможность плюсов в идее автора или ему и делиться этим не стоило?
Ну, Ок. А пена-то зачем? Почему эта "лютая дичь" вызвала у Вас столько эмоций?
Кстати, да. Есть у хранимок такой аспект — при миграции в другую СУБД код самого приложения может и не придется менять вообще. А только эти хранимки.
Я участвовал в проекте миграции Ora -> Pg, где доступно было только то, что лежит в Ora. Там была одна проблема — старый код хранимок не имел тестов, пришлось их сначала писать. А какой используется "обычный ЯП" и есть ли вообще исходники — значения не имело.
Ну да, разобраться не могут и годами развивают. Я б на такое посмотрел)
И переписать — это не единственный вариант, для телекома полно даже коробочных решений и если был бы смысл — давно бы переехали, полагаю.
При разработке, на каждый чих, можно и просто файл накатить через тот же psql. Но в общем случае, в т.ч. при деплое — да, удаляем схемы и создаем заново, в одной транзакции с тестами.
Да, это, на мой взгляд, косяк автора — не смог найти слова, чтобы его поняли правильно. Я сбился со счета, сколько раз ему в итоге пришлось постить разъяснения вроде этого. Если не хотите, чтобы он еще раз повторил, предлагаю остановиться на моей версии. По ней это "если произошли" надо читать как "если в БД произошли".
Если я правильно понял посыл автора, то он в том, что есть плюсы от размещения в БД логики, которая оперирует только данными, размещенными в этой же БД. В этом смысл хранимки — держать код рядом с данными. Да, технически можно из БД лезть куда-то еще и иногда это даже оправдано, но статья не об этой технике.
Т.о. на Ваш вопрос ответ такой — интеграционные тесты делаем как обычно, за рамками БД.
Есть варианты, в т.ч. pgtap, но тут ничего сложного и дело вкуса, можно повелосипедить, например так:
-- Пример для функции `rpc.func_args(TEXT)` которая возвращает строку таблицы
SELECT pgmig.assert_eq('func_args' -- название теста
, (SELECT row_to_json(r) FROM rpc.func_args('func_args') r)::jsonb -- got
, '{
"arg": "a_code",
"anno": "Имя процедуры",
"type": "text",
"def_val": null,
"required": true
}' -- want
);
ROLLBACK TO SAVEPOINT test_begin; -- откатить изменения, если они были
выполняется в той же транзакции, что и создание функции. Если assert_eq вызовет EXCEPTION — транзакции не будет
Спасибо автору за тему и будет интересно почитать подробности.
Но, думаю, вы зря считаете, что такие решения стали возможны только с поддержкой JSON. Вариант, когда хранимка имеет список типизированных аргументов и возвращает таблицу, был доступен гораздо раньше и до сих пор имеет плюсом то, что весь АПИ автодокументируется довольно просто. Хоть в swagger, хоть в protobuf.
А скептикам, которые уверены, что подобная архитектура долго не протянет, замечу, что все зависит от людей. А сам SQL консервативен, там не выходит несовместимых версий и хранимки вполне себе живут в проде и 10 лет и 17. И те, кто их не создал, но допиливает, могут быть довольны этим процессом, как и заказчик.
Вроде автор писал, что возвращают они коды, а вот текст сообщения — это уже про локализацию. И действительно, выглядит странно… для всех, кто не знает, как одним `SET SEARCH_PATH..` поменять язык ответов БД.
На мой взгляд - нормальный ответ. Если так сделано фреймворком, то, как минимум, стоит с такого начать. Если вопрос - к его разработчикам, но он задан не там, но полагаю, авторы нашли бы, что ответить.
И, раз позднее проблему решили, в ней не было ничего концептуального. Полагаю, до выхода в прод не нашлось причины переделать это место.
Да ничего подобного. Если у вас при выходе в прод оказалось, что какая-то транзакция начала залипать, значит можно сформулировать тест на количество таких операций в секунду, который развалился бы и в момент приемки. И если бы этот тест был в ТЗ, вы бы избежали полугода боли. Точно ли тут виноват разработчик (а он компетентен, раз исправил в итоге) или, все-таки, ТЗ оказалось не вполне адекватным?
del
Про
FOR UPDATE .. SKIP LOCKED, полагаю, отлично расписали в документации - "Skipping locked rows provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table". И да, пост depesz про эту фичу в свое время был как глоток свежего воздуха для тех, кто пилил очереди. Результат в проде 10+ лет, к слову.pg_advisory_lock.. тут пишут - "There are two ways to acquire an advisory lock in PostgreSQL: at session level or at transaction level." Вы о каком? Тут бы не помешала конкретика, с 97го пару раз встречал кейсы, где это пригодилось (не считая, конечно, тех кейсов, которые разработчиков СУБД убедили эту фичу запилить)
PS. "при реальных пользователях нет" читается как "пока не научились писать адекватные тесты"
А нет ли у вас конкретики о том, почему не подошел вариант "для своей сети поднимем свой CA и к нему прикрутим свой аналог LE"?
Для reverse-proxy и сертификатов с динамическим добавлением хостов можно посмотреть на Traefik. Рабочий пример, где все это собрано вместе - dcape
20+ лет пишу хранимки в PG, давно читаю хабр, вдруг оказалось, что тут можно постить до знакомства с разработкой и редакторами. Впечатлен.
Разумеется, и теплое и мягкое имеют свои причины. Про второе, полагаю, все очевидно. А про первое — это ли не js породил?)
Как автор аналогичного проекта, впечатлен. Те, кто сейчас его поддерживают в проде, давненько на perl ничего не писали. И даже если в проекте есть "ад", искали бы его не в БД.
И да, это не про контроль версий или автотесты, там это все было сразу.
В масштабах тиражей Oracle, полагаю, более чем так.
Или это — ниша, которую еще никто не смог заполнить. Может, недостает пары идей, чтобы решения, которые радуют лишь некоторых, понравились многим.
Вы сменили тему ветки, но поддержу) Я тоже считаю, что "потеря данных неприемлема", но, в моем случае, считаю это профессиональной деформацией. Да, в банке такой прокол легко измерим деньгами и виновного можно найти и выставить на зарплату всей его остальной жизни. Но вот в других сферах бизнеса я с изумлением наблюдал совершенно иное, в духе "ну ладно, перезальем эти файлы" или "что ж, в этом месяце подняли чуть меньше"… там топам даже искать виновного бывает лень. И тут я вполне допускаю, что какие-то потери ради некоторых плюсов (вроде не положить весь сервис на близком пике) могут быть и оправданы и априори приемлемы… Да, после пика можно бы вернуться к проблеме и все-таки эти данные восстановить. Но "не смогли" и "не захотели" — это разные варианты и оба они к теме текущей статьи, на мой взгляд, отношения не имеют.
Ваш пост о том, что вы отрицаете возможность плюсов в идее автора или ему и делиться этим не стоило?
Ну, Ок. А пена-то зачем? Почему эта "лютая дичь" вызвала у Вас столько эмоций?
А для меня выглядит так, что кроме кода ошибки есть еще какие-то атрибуты)
И там еще ниже было:
Кстати, да. Есть у хранимок такой аспект — при миграции в другую СУБД код самого приложения может и не придется менять вообще. А только эти хранимки.
Я участвовал в проекте миграции Ora -> Pg, где доступно было только то, что лежит в Ora. Там была одна проблема — старый код хранимок не имел тестов, пришлось их сначала писать. А какой используется "обычный ЯП" и есть ли вообще исходники — значения не имело.
Ну да, разобраться не могут и годами развивают. Я б на такое посмотрел)
И переписать — это не единственный вариант, для телекома полно даже коробочных решений и если был бы смысл — давно бы переехали, полагаю.
При разработке, на каждый чих, можно и просто файл накатить через тот же psql. Но в общем случае, в т.ч. при деплое — да, удаляем схемы и создаем заново, в одной транзакции с тестами.
Да, это, на мой взгляд, косяк автора — не смог найти слова, чтобы его поняли правильно. Я сбился со счета, сколько раз ему в итоге пришлось постить разъяснения вроде этого. Если не хотите, чтобы он еще раз повторил, предлагаю остановиться на моей версии. По ней это "если произошли" надо читать как "если в БД произошли".
Если я правильно понял посыл автора, то он в том, что есть плюсы от размещения в БД логики, которая оперирует только данными, размещенными в этой же БД. В этом смысл хранимки — держать код рядом с данными. Да, технически можно из БД лезть куда-то еще и иногда это даже оправдано, но статья не об этой технике.
Т.о. на Ваш вопрос ответ такой — интеграционные тесты делаем как обычно, за рамками БД.
Есть варианты, в т.ч. pgtap, но тут ничего сложного и дело вкуса, можно повелосипедить, например так:
выполняется в той же транзакции, что и создание функции. Если assert_eq вызовет EXCEPTION — транзакции не будет
Но, думаю, вы зря считаете, что такие решения стали возможны только с поддержкой JSON. Вариант, когда хранимка имеет список типизированных аргументов и возвращает таблицу, был доступен гораздо раньше и до сих пор имеет плюсом то, что весь АПИ автодокументируется довольно просто. Хоть в swagger, хоть в protobuf.
А скептикам, которые уверены, что подобная архитектура долго не протянет, замечу, что все зависит от людей. А сам SQL консервативен, там не выходит несовместимых версий и хранимки вполне себе живут в проде и 10 лет и 17. И те, кто их не создал, но допиливает, могут быть довольны этим процессом, как и заказчик.