Так кейсы теже что и для реактивного стека по сути(он аналогично не везде нужен), плюс стоит отметить, что первый lts (25) с фиксом synchronized блоков вышел и можно брать виртуальные потоки в прод
Заметил что если в открытом доступе нет примеров использования какой то библиотеки то пытаться просить ии что то написать нет смысла. А откуда будут браться примеры и документация если их никто не будет писать руками? Опять же выходит новая библиотека что нужно ждать когда гпт новый выйдет? Вообщем выглядит пока что всё это не очень
На самом деле в этом lts релизе много изменений по сравнению с предыдущим lts. Как будто не все понимают что этот релиз содержит фичи из 22, 23, 24 версии и теперь это lts.
Просто если речь про rps < 1000, то о какой деградации идёт речь? На таких объёмах проще все синхронно делать не те объёмы. Если же rps > 1000 то с постгресом тут будет очень сложно. Проще outbox сделать в rabbit, а уже оттуда при чтении делать несколько транзакций в разных системах хоть синхронно хоть асинхронно. Outbox на базе очень узкоспециализированный кейс.
Ах да и самое главное не нужно менять синхронный контракт на асинхронный только для того чтобы сделать систему устойчивой. Начать хотя бы с того что теряется обратная связь, кривая обработка ошибок, попытки сделать обработку ответов в обратном топике. Для этого есть готовые подходы например cb, грамотные ретраи и другое. На хабре про это тонны материала.
А graalpy чем не нравится? И причём тут spring? Кейсы применения непонятны. Такие аннотации обычно в коде руками реализовывают, если они действительно нужны.
Так а в чем проблема то? Вам дали возможность привязать структуру таблиц к модели и понятные правила формарования запросов. Нужно целиком загрузить зависимости используй eager или entitygraph, не нужно используй lazy. Опять же аннотация OneToMany описывает связь табоиц. В этом и есть удобство не нужно руками писать запросы. Особенно удобно на мой вгляд, что hibernate следит за изменениями модели и сам формирует вставки, удаления, изменения дочерних коллекций. Остаётся просто писать бизнес код. Если подобную логику делать самому получится просто свой велосипед.
А зачем тогда аннотации для привязки сущности к таблице? Id, Column, Table...? JPQL? На мой взгляд ни кто и не собирался ничего прятать. А вы что хотели бы в проде на каждый запрос видеть логи реальных запросов? Какой в этом смысл?
JPA/ORM это не про то, чтобы не думать об sql, а чтобы удобнее было работать со сложными моделями. Проблема не в инструменте, а в том как вы его используете. И да этот инструмент в действительности нужен в очень небольшом кол-ве проектов. На моей команде всего 1 такой, в остальных местах sql/cql. Причём при работе с cassandra не используем спринг репозитории, нашли там неприятный баг, влияющий на перфоманс.
На самом деле orm классная вещь для сложной доменной модели. Подчеркну только для неё. Если модель простая, то никакой orm вообще не нужен и не нужно даже его рассматривать. Это обычно сложные проекты для зрелых команд, со сложной бизнес логикой.
Но нужно соблюдать
Разделение на агрегаты. ManyToOne в нашей команде под жестким запретом.
Использовать entity graph для получения правильных запрсов.
Не использовать дефолтные репозитории(по первой причине)
Писать свои миграции и схему. Доверять автогенерации я бы точно не стал
Почитать как оно работает под капотом. Инструмент не для новичков
Если же пытаться работать со сложной модель на jdbc получается очень много кода, это делать можно, но поддержка и развитие проекта будет дороже
А вы видели чтобы кто нибудь когда нибудь синхронизировался на value-based типах. Что это может быть за кейс? Или может быть на реальный баг натыкались? Я просто за 15 лет такого не встречал.
JEP 390 для подготовки к valhalla, там собственно про это и написано.
На самом деле описать схему протобаф по dto модели это 5 минут пользуясь тем же чатгпт или дипсик. Опять же в случае с grpc вы получаете проверенный оттестированый транспорт, асинхронный клиент из коробки. Не понимаю правда зачем в 2025 городить свой rpc.
Ещё вопрос, а тестировать как руками? С рестом понятно, для grpc сейчас тоже есть клиенты. Будете ещё тулинг писать к своему протоколу?
Так я не про память ram, я про диск. Каждое обновление создает новую версию той же строки, периодически запускается avtovacuum для очистки старых значений + обновление индекса, это достаточно жирные процессы. Может создаваться ситуация когда нагрузка при каждом следующем vacuum увеличивается и в конечном счёте через день два получаем колом вставшую базу. Видел такое на проде. Поэтому тест этот нужно гонять и смотреть на всю систему и все процессы. Причем гонять именно сутками, даже за час вы эту деградацию скорее всего не увидите. Можно конечно использовать unlogged таблицы которые не пишут wal(при сбое данные пропадут). Но тогда зачем тут постгрес?
Так кейсы теже что и для реактивного стека по сути(он аналогично не везде нужен), плюс стоит отметить, что первый lts (25) с фиксом synchronized блоков вышел и можно брать виртуальные потоки в прод
Заметил что если в открытом доступе нет примеров использования какой то библиотеки то пытаться просить ии что то написать нет смысла. А откуда будут браться примеры и документация если их никто не будет писать руками? Опять же выходит новая библиотека что нужно ждать когда гпт новый выйдет? Вообщем выглядит пока что всё это не очень
Как будто это единственный способ? CAS?
На самом деле в этом lts релизе много изменений по сравнению с предыдущим lts. Как будто не все понимают что этот релиз содержит фичи из 22, 23, 24 версии и теперь это lts.
Просто если речь про rps < 1000, то о какой деградации идёт речь? На таких объёмах проще все синхронно делать не те объёмы. Если же rps > 1000 то с постгресом тут будет очень сложно. Проще outbox сделать в rabbit, а уже оттуда при чтении делать несколько транзакций в разных системах хоть синхронно хоть асинхронно. Outbox на базе очень узкоспециализированный кейс.
Ах да и самое главное не нужно менять синхронный контракт на асинхронный только для того чтобы сделать систему устойчивой. Начать хотя бы с того что теряется обратная связь, кривая обработка ошибок, попытки сделать обработку ответов в обратном топике. Для этого есть готовые подходы например cb, грамотные ретраи и другое. На хабре про это тонны материала.
И на какую нагрузку рассчитано всё это? Очередь в postgres довольно узкое место будет
А graalpy чем не нравится? И причём тут spring? Кейсы применения непонятны. Такие аннотации обычно в коде руками реализовывают, если они действительно нужны.
Думаю стоит остановиться в этом бессмысленном споре
Так а в чем проблема то? Вам дали возможность привязать структуру таблиц к модели и понятные правила формарования запросов. Нужно целиком загрузить зависимости используй eager или entitygraph, не нужно используй lazy. Опять же аннотация OneToMany описывает связь табоиц. В этом и есть удобство не нужно руками писать запросы. Особенно удобно на мой вгляд, что hibernate следит за изменениями модели и сам формирует вставки, удаления, изменения дочерних коллекций. Остаётся просто писать бизнес код. Если подобную логику делать самому получится просто свой велосипед.
Как бы вы решили задачу, которую решает JPA?
А зачем тогда аннотации для привязки сущности к таблице? Id, Column, Table...? JPQL? На мой взгляд ни кто и не собирался ничего прятать. А вы что хотели бы в проде на каждый запрос видеть логи реальных запросов? Какой в этом смысл?
JPA/ORM это не про то, чтобы не думать об sql, а чтобы удобнее было работать со сложными моделями. Проблема не в инструменте, а в том как вы его используете. И да этот инструмент в действительности нужен в очень небольшом кол-ве проектов. На моей команде всего 1 такой, в остальных местах sql/cql. Причём при работе с cassandra не используем спринг репозитории, нашли там неприятный баг, влияющий на перфоманс.
На самом деле orm классная вещь для сложной доменной модели. Подчеркну только для неё. Если модель простая, то никакой orm вообще не нужен и не нужно даже его рассматривать. Это обычно сложные проекты для зрелых команд, со сложной бизнес логикой.
Но нужно соблюдать
Разделение на агрегаты. ManyToOne в нашей команде под жестким запретом.
Использовать entity graph для получения правильных запрсов.
Не использовать дефолтные репозитории(по первой причине)
Писать свои миграции и схему. Доверять автогенерации я бы точно не стал
Почитать как оно работает под капотом. Инструмент не для новичков
Если же пытаться работать со сложной модель на jdbc получается очень много кода, это делать можно, но поддержка и развитие проекта будет дороже
А вы видели чтобы кто нибудь когда нибудь синхронизировался на value-based типах. Что это может быть за кейс? Или может быть на реальный баг натыкались? Я просто за 15 лет такого не встречал.
JEP 390 для подготовки к valhalla, там собственно про это и написано.
Ошибка конечно джуновая
На самом деле описать схему протобаф по dto модели это 5 минут пользуясь тем же чатгпт или дипсик. Опять же в случае с grpc вы получаете проверенный оттестированый транспорт, асинхронный клиент из коробки. Не понимаю правда зачем в 2025 городить свой rpc.
Ещё вопрос, а тестировать как руками? С рестом понятно, для grpc сейчас тоже есть клиенты. Будете ещё тулинг писать к своему протоколу?
Почему не взять grpc? Автогенерация для большинства популярных языков и фреймворков. Чем ваш подход лучше?
Так я не про память ram, я про диск. Каждое обновление создает новую версию той же строки, периодически запускается avtovacuum для очистки старых значений + обновление индекса, это достаточно жирные процессы. Может создаваться ситуация когда нагрузка при каждом следующем vacuum увеличивается и в конечном счёте через день два получаем колом вставшую базу. Видел такое на проде. Поэтому тест этот нужно гонять и смотреть на всю систему и все процессы. Причем гонять именно сутками, даже за час вы эту деградацию скорее всего не увидите. Можно конечно использовать unlogged таблицы которые не пишут wal(при сбое данные пропадут). Но тогда зачем тут постгрес?
Тут интресно что там с vacuum на постргрес, ресурсов будет потреблять на порядок больше, особенно io
А может это специально созданный алгоритм для введения противника в заблуждение?
События в бд не надёжно. Только репликация и полинг даст хорошую гарантию.