Здравствуйте, Sharov, Вы писали:

S>Зачем переписывать? Там же добавлять для connection'а добавлять sql код, который надо выполнить. Т.е. если
S>идет манипуляция с какими-нибудь сущностями, то при открытия соединения или непосредственно запроса добавить
S>какой-нибудь sql код. По идее любая приличная ORM это умеет.

Да, я нагуглил прикольное короткое решение через кастомный диалект Хайбернейта, но в долгосрочной перспективе мне больше подходит jOOQ для этих сценариев.

Я просто устал уже бороться с Hibernate. Одно поле где-то добавишь, внезапно быстрый селект превращается в необъяснимый N+1. Вешаешь fetch=lazy, всё равно подтягивает зачем-то. Через N+1. Мне эти данные вот в этом сценарии нафиг не нужны, блин. Начинаешь гуглить, там такие бодрые посты от инсайдеров хайбернейта: "вы могли удивиться, увидев что иногда fetch=lazy оказывается не lazy" — и дальше идёт прекрасное подробное объяснение почему так. Или там -to-many связь добавляешь, хайбернейт начинает паджинацию делать в памяти — вытягивает всю базу, все 500К записей и обрезает в памяти. Ну да, ворнинг в лог пишет, молодец. Для меня это просто не работает, хайбернейт — это какая-то нелепая уродливая технология, которая на ровном месте дарит кучу неприятных сюрпризов. Самое отвратительное — он не даёт абсолютно никаких инструментов для того, чтобы обнаруживать проблемы, пусть если не на этапе компиляции, то хоть с помощью инт тестов.

Вот у меня есть простая хотелка: я хочу, чтобы N+1 никогда не было. Вообще никогда, ни при каких обстоятельствах. Чтобы всё к херам падало вместо N+1 за 120 секунд в продакшне. Ключевые слова: "хрен", "внимательность", "трассировка" и "усидчивость". Я видел, что есть какие-то левые детекторы N+1, но меня реально вгоняет в депрессию: этот костыль для обнаружения N+1, этот костыль для детекта лишних джойнов. Давайте может вообще тогда снапшоты запросов снимать и хардкодить их в тесты? Ну потому что ведь проблемы лучше видеть явно, чем косвенно. Мне повезло — у меня есть перформанс тесты, я каждую глупость ловлю не позже, чем через 24 часа и это здорово работает с учётом того, что релизы мы делаем раз в неделю. Но меня задолбало уже. Я 10 лет использую этот грёбаный хайбернейт в десятке проектов, и чем дальше, тем больше нужно знать и помнить. Нет, это не то, как должна выглядить хорошая технология.

Ну у меня read-heavy сервис, я конечно оставлю Хайбернейт для PUT/DELETE сценариев. Но вот /things?skip=10&limit=20&filter=...&soryBy=qwerty&sortOrder=asc — ну нафиг, тут только jOOQ, только 100% предсказуемые запросы и возможность легко всё перевернуть с ног на голову, если потребуется. Hibernate здесь просто лишняя сущность.

Здравствуйте, Sharov, Вы писали:

S>Зачем переписывать? Там же добавлять для connection'а добавлять sql код, который надо выполнить. Т.е. если
S>идет манипуляция с какими-нибудь сущностями, то при открытия соединения или непосредственно запроса добавить
S>какой-нибудь sql код. По идее любая приличная ORM это умеет.

Да, я нагуглил прикольное короткое решение через кастомный диалект Хайбернейта, но в долгосрочной перспективе мне больше подходит jOOQ для этих сценариев.

Я просто устал уже бороться с Hibernate. Одно поле где-то добавишь, внезапно быстрый селект превращается в необъяснимый N+1. Вешаешь fetch=lazy, всё равно подтягивает зачем-то. Через N+1. Мне эти данные вот в этом сценарии нафиг не нужны, блин. Начинаешь гуглить, там такие бодрые посты от инсайдеров хайбернейта: "вы могли удивиться, увидев что иногда fetch=lazy оказывается не lazy" — и дальше идёт прекрасное подробное объяснение почему так. Или там -to-many связь добавляешь, хайбернейт начинает паджинацию делать в памяти — вытягивает всю базу, все 500К записей и обрезает в памяти. Ну да, ворнинг в лог пишет, молодец. Для меня это просто не работает, хайбернейт — это какая-то нелепая уродливая технология, которая на ровном месте дарит кучу неприятных сюрпризов. Самое отвратительное — он не даёт абсолютно никаких инструментов для того, чтобы обнаруживать проблемы, пусть если не на этапе компиляции, то хоть с помощью инт тестов.

Вот у меня есть простая хотелка: я хочу, чтобы N+1 никогда не было. Вообще никогда, ни при каких обстоятельствах. Чтобы всё к херам падало вместо N+1 за 120 секунд в продакшне. Ключевые слова: "хрен", "внимательность", "трассировка" и "усидчивость". Я видел, что есть какие-то левые детекторы N+1, но меня реально вгоняет в депрессию: этот костыль для обнаружения N+1, этот костыль для детекта лишних джойнов. Давайте может вообще тогда снапшоты запросов снимать и хардкодить их в тесты? Ну потому что ведь проблемы лучше видеть явно, чем косвенно. Мне повезло — у меня есть перформанс тесты, я каждую глупость ловлю не позже, чем через 24 часа и это здорово работает с учётом того, что релизы мы делаем раз в неделю. Но меня задолбало уже. Я 10 лет использую этот грёбаный хайбернейт в десятке проектов, и чем дальше, тем больше нужно знать и помнить. Нет, это не то, как должна выглядить хорошая технология.

Ну у меня read-heavy сервис, я конечно оставлю Хайбернейт для PUT/DELETE сценариев. Но вот GET /things?skip=10&limit=20&filter=...&soryBy=qwerty&sortOrder=asc — ну нафиг, тут только jOOQ, только 100% предсказуемые запросы и возможность легко всё перевернуть с ног на голову, если потребуется. Hibernate здесь просто лишняя сущность.