Как стать автором
Обновить

Комментарии 6

@Query(
"""select * from jgproj_api.f_search_project_by_name(
p_search_text => cast(:search_text as text),
p_user_id => cast(cast(:user_id as text) as bigint),
p_offset=> :offset,
p_limit=> :limit,
p_sort=> cast(:sort as text))""",
nativeQuery = true
)

Господа, но ведь это жесть неподдерживаемая! У exposed-а ведь есть мощная dsl, которая сильно помогает не ошибиться в названии поля, и в случае каких-либо правок в слое базы, весь ошибочны код даже не скомпилится. Почему здесь вы такой подход не использовали?

Я ведь правильно понимаю, что в случае, который вы описываете (к сожалению, exposed еще только пробуем, в боевых условиях пока не использовали) все равно придется "опускаться до таблиц"? А мы то хотели все-таки сделать это через "изолированный слой". Да, это такой осознанный риск, что ли. Вернее не сколько риск, а решение.

Ну и плюс тесты то все равно же, если они написаны, отработают ситуацию. А мы их пишем, у нас много тестов.

Но спасибо, обратим внимание на exposed dsl, а может и придумаем что-то подобное, применительно к нашему решению.

Нет, в exposed есть вполне себе типобезопасная обёртка entity. Так что с полями трудно ошибиться, т.к. они являются полями entity. А api entity максимально приближён к sql запросу. Собственно как и весь dsl exposed. Но есть минусы: нет поддержки хранимых процедур и при большом объёме запросов лучше пользоваться api Table вместо Entity (Всё ещё типобезопасно, но накосячить проще). Из плюсов - инициализация схемы базы данных очень даже минималистичная.

А как вы сочетаете договариваться о контрактах в чатах и генерировать сваггер доки из кода? Спрашиваю потому, что по идее эти доки и есть контракт, который уже обговорили, на основе которого (по идее) как бы бэкенд и делается, как, впрочем, и фронтенд.

Вы сначала описываете контракт формально, а потом еще и OpenAPI спеку генерите из того, что получилось? И потом тестеры руками сравнивают то, о чем было договорено и то, что нагенерилось? Я просто не совсем понимаю смысл генерации спеки из того, что может быть потенциально некорректно реализовано (что, в свою очередь, сгенерирует кривую спеку), мне субъективно кажется более логичным написать спеку на контракт, и потом сделать кодогенерацию по ней, чем наоборот. Опять же, так было бы проще искать некоторые баги, вместо того, чтобы выяснять, где правильно - там, где договорено, или там, где реализовано.

Отвечу. У нас как то так исторически сложилось, что бэкенд стартовал раньше фронта, поэтому какое то время мы придумывали эндпоинты вообще сами как хотели, потом уже изменили правила игры и стало так:

  • Мы встречаемся (в чатах, на созвонах) с фронтами - т.е. заинтересованные от бэка и фронта и проговариваем вообще всю "смысловую" часть, т.е. более менее крупными мазками, что как, когда и куда поедет;

  • Фиксируем все это дело в конфлюенс;

  • Ну и идем разрабатывать код. При этом при разработке конечно могут быть уточнения и т.д. и вот я бы не стал закладываться на 100% верности версии в конфлюенс (ну, может быть забыли обновить или чего то не заметили), но она служит неким "смысловым" ориентиром. А вот версия из кодогенерации из сваггера - она да, она самая огонь, она неактуальной быть не может;

  • Тестеры уже тестирую всю фичу, реализованную как на фронте, так и на бэке, в конфлюенс с контрактами особо не заглядывая, это как бы мы для себя;

Вроде работает такая схема. Пока никуда с нее не уходим. Более того, фронты с нашего сваггера генерят себе какие то там модели или код (ну, вообщем что то генерят), поэтому добиваются чтобы он у нас был максимально чистым (нулл, нот нулл - все это важно для них).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий