Как я уже отвечал выше, таких мест было достаточно много, и если все из них переписать через @Query(native=true), то это не сильно бы отличалось от того, что в итоге получилось.
Модель entitей на этом проекте особо не используется по назначению: в большинстве мест мы просто достаем записи из бд.
А хранить сгенереные классы в репозитории - это весьма опасный путь.
Этот минус нашего подхода я подсветил в статье. Мы на него согласились в угоду стабильности тестов и более быстрой сборки проекта.
Да, такой вариант был. Однако таких мест было достаточно много, и если все из них переписать через @Query(native=true), то это не сильно бы отличалось от того, что в итоге получилось. К тому же большинство из них содержали джойны и доставали не все данные, и чтобы это нормально работало пришлось бы также писать много интерфейсов-проекций.
В нашем случае из необходимых фичей были только кэши, поэтому мы их без труда прикрутили на уровне сервиса. Работа с транзакциями происходит через API , но у нас не было необходимости открывать транзакцию руками.
Проделанная работа позволила значительно оптимизировать работу с БД, поэтому ее сложно назвать лишней. В добавок статья как раз о том, что нам это удалось сделать достаточно быстро, прикрутив кодогенерацию - оставалось только переписать запросы, что затратило бы столько же времени, как если бы делали через @Query
Как я уже отвечал выше, таких мест было достаточно много, и если все из них переписать через @Query(native=true), то это не сильно бы отличалось от того, что в итоге получилось.
Модель entitей на этом проекте особо не используется по назначению: в большинстве мест мы просто достаем записи из бд.
Этот минус нашего подхода я подсветил в статье. Мы на него согласились в угоду стабильности тестов и более быстрой сборки проекта.
Так у нас и сейчас только один механизм работы с БД - jOOQ.
Писали. В своем ответе я и написал «также», имея ввиду что это пришлось бы делать в обоих случаях.
Да, такой вариант был. Однако таких мест было достаточно много, и если все из них переписать через @Query(native=true), то это не сильно бы отличалось от того, что в итоге получилось. К тому же большинство из них содержали джойны и доставали не все данные, и чтобы это нормально работало пришлось бы также писать много интерфейсов-проекций.
В нашем случае из необходимых фичей были только кэши, поэтому мы их без труда прикрутили на уровне сервиса. Работа с транзакциями происходит через API , но у нас не было необходимости открывать транзакцию руками.
Проделанная работа позволила значительно оптимизировать работу с БД, поэтому ее сложно назвать лишней. В добавок статья как раз о том, что нам это удалось сделать достаточно быстро, прикрутив кодогенерацию - оставалось только переписать запросы, что затратило бы столько же времени, как если бы делали через @Query
Спасибо за уточнение, поправил!