A
3 - точно нет. Как вы себе представляете объединить это с коверейджем от кода приложения?
Просто воспринимай в таком случае бд как отдельный микросервис, а хранимки - как api этого микросервиса.
Size: a a a
2021 January 12
A
У тебя же не возникает вопросов, как мокать для тестирования своего кода другой микросервис?
ДТ
Помогите
execute 'insert into status(user_name, day, count) values($1,0,0)' using row.user_name;
D
Alexander
У тебя же не возникает вопросов, как мокать для тестирования своего кода другой микросервис?
Нет. Но как в хранимке делать и мокать потом в тесте обращение к другим сервисам - возникает
IZ
Создай это нещастное поле в таблице, и всё будет ок
W
Нет. Но как в хранимке делать и мокать потом в тесте обращение к другим сервисам - возникает
А дай пример того как хранимка обращается к внешнему сервису. Конкретно у тебя.
A
Нет. Но как в хранимке делать и мокать потом в тесте обращение к другим сервисам - возникает
А у тебя ещё и хранимка в другой сервис ходит, а не только в базу?
IZ
Alexander
А у тебя ещё и хранимка в другой сервис ходит, а не только в базу?
Вот хранимка, ходящая в другой сервис - это криминал уже...
D
Alexander
А у тебя ещё и хранимка в другой сервис ходит, а не только в базу?
У меня вообще хранимок нет. Но если бизнес-логику делать на хранимках, то это вполне себе реальный кейс
W
У меня вообще хранимок нет. Но если бизнес-логику делать на хранимках, то это вполне себе реальный кейс
Ну тогда функция подключения к внешнему сервису в отдельный пакет и махинации с search_path. Чем тебе не мок?
W
Вот хранимка, ходящая в другой сервис - это криминал уже...
pl/perlu ^_^
A
У меня вообще хранимок нет. Но если бизнес-логику делать на хранимках, то это вполне себе реальный кейс
В хранимках надо делать ту бизнес-логику, которая, максимум, касается только данных в базе. Все остальное - это уже однозначно работа для бэкенда на нормальном языке
D
Alexander
В хранимках надо делать ту бизнес-логику, которая, максимум, касается только данных в базе. Все остальное - это уже однозначно работа для бэкенда на нормальном языке
Тогда какой смысл бизнес-логику так размазывать? Часть будет в коде, часть в базе...
Ss
execute 'insert into status(user_name, day, count) values($1,0,0)' using row.user_name;
спасибо
D
Ну тогда функция подключения к внешнему сервису в отдельный пакет и махинации с search_path. Чем тебе не мок?
Геморрой же полный
A
Тогда какой смысл бизнес-логику так размазывать? Часть будет в коде, часть в базе...
Потому что в некоторых случаях имеет смысл представить БД другим микросервисам не кишками наружу, а в виде микросервиса-хранилища. Например, когда тебе надо, чтобы доступ к данным получали несколько сервисов. Можно оформить интерфейс к данным в виде сервиса-обертки на полноценном языке, а можно в виде хранимок, и пустить другие сервисы прям базе (разрешив работать только через интерфейс хранимок, разумеется).
A
И будет у тебя не
GET /api/v1/user/i.ivanov
а
select v1_getuser('i.ivanov');
GET /api/v1/user/i.ivanov
а
select v1_getuser('i.ivanov');
D
Alexander
Потому что в некоторых случаях имеет смысл представить БД другим микросервисам не кишками наружу, а в виде микросервиса-хранилища. Например, когда тебе надо, чтобы доступ к данным получали несколько сервисов. Можно оформить интерфейс к данным в виде сервиса-обертки на полноценном языке, а можно в виде хранимок, и пустить другие сервисы прям базе (разрешив работать только через интерфейс хранимок, разумеется).
Если так, то да. Но, опять-таки, если учитывать, что в хранимке нельзя делать обращение к внешним сервисам, то это всё годится лишь для совсем каких-то простейших случаев, где запросы строго в одну БД и больше ничего нет.
A
Если так, то да. Но, опять-таки, если учитывать, что в хранимке нельзя делать обращение к внешним сервисам, то это всё годится лишь для совсем каких-то простейших случаев, где запросы строго в одну БД и больше ничего нет.
Ясное дело, что это не универсальный рецепт, и он применим только при определенной архитектуре, спроектированной под определенные требования.
Но бывают такие ситуации, когда тебе нужно сделать микросервис-хранилище, чтобы в нем держать весь стейт, не размазывая его по куче микросервисов, у каждого из которых по своей базе, имея при этом головняк с консистентностью данных и связей между ними.
Но бывают такие ситуации, когда тебе нужно сделать микросервис-хранилище, чтобы в нем держать весь стейт, не размазывая его по куче микросервисов, у каждого из которых по своей базе, имея при этом головняк с консистентностью данных и связей между ними.
D
Alexander
Ясное дело, что это не универсальный рецепт, и он применим только при определенной архитектуре, спроектированной под определенные требования.
Но бывают такие ситуации, когда тебе нужно сделать микросервис-хранилище, чтобы в нем держать весь стейт, не размазывая его по куче микросервисов, у каждого из которых по своей базе, имея при этом головняк с консистентностью данных и связей между ними.
Но бывают такие ситуации, когда тебе нужно сделать микросервис-хранилище, чтобы в нем держать весь стейт, не размазывая его по куче микросервисов, у каждого из которых по своей базе, имея при этом головняк с консистентностью данных и связей между ними.
Тогда ясно