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

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

Очень ̶у̶д̶о̶б̶н̶о̶ нет конечно - код в виде скриншотов.

Так пример можно по ссылке посмотреть

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

Так в hibernate 6 специально сделали диалекты, которые да сложнее писать, зато потом будет меньше самописного шлака и велосипедов вокруг фреймворка если нужно что-то кастомное.

Но если например захотете сменить фреймворк, то придется все переписывать. А с нативным sql не придется.

посмотреть на GitGub

Поправьте Gub, а то подумалось что что-то новенькое, ан нет

Добрый день!

Спасибо, что заметили

Добрый день!

мне удалось устранить большое количество проблем, связанных с неоптимальной интеграцией функциональности PostgresSQL в Java-приложениях

Несколько раз перечитал, но понял что вы тут написали в самом конце. "В Java-приложениЕ" сразу меняет смысл.

Да и в целом язык мог бы быть гораздо проще. На много проще. Вы ж не космический корабль описываете.

Ну типа вот так. Была у нас проблема - приходилось запросы к JSONB сочинять путём конкатенации строк. Это сильно захламляло исходники. А я придумал, как это загнать это в ORM. Вы же, что там билдите, насаждаете, стеки какие-то. В общем, тяжело это читать.

Вот вы говорите, что сделали хорошо. А что собственно улучшилось не приводите. Весь смысл телодвижений вроде именно в улучшениях. А то, что вы заставили какой-то ORM плясать под вашу дуду, мне ни о чем не говорит. Я знаю огроменные приложения, где, кроме конкатенации строк нет ничего. Они прекрасно работают и в ус не дуют. И никакого бардака, кроме известного, в них нет.

А вот наоборот видел много раз. Как только ORM встречается с объёмами данных больше тестовых, всё летит к чертям собачьим.

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