Comments 7
Проблема N+1 характерна для разных языков программирования.
При чём тут ЯП, если это проблема с ORM-библиотекой?
это проблема выбора скорости работы с БД. просто автор выразился иначе. сделай все однопоточно, кэшированно, супер-безопасно, загрузи все зараз и жди, жди, жди... . ну положешь сервер или клиента в худшем случае из-за кэша, память нагрузится - это пройдет. или получи какой-то % информации супер-быстро, супер-просто, но что тебя ждет дальше - не знает никто...
Сложно вам отвечать, поскольку очевидно, что статью вы не читали. Вы вырвали фразу из контекста, вложили в нее какой-то свой смысл, сами с собой не согласились и, основываясь на выдуманном противоречии, стали настаивать на том, что автор и не пытался оспаривать. В том месте, на которое вы ссылаетесь, начало статьи, первое, вводное предложение, там просто формулируется контекст, фактически там говорится, что столкнуться с проблемой N+1 можно в любом языке. Если б вы потрудились прочитать второе предложение, то увидели бы там название ORM-библиотеки. И еще, если б вы прочитали статью, то узнали бы, что в данном случае проблема не с ORM-библиотекой, а с её неправильным использованием. Учитывайте при работе с Hibernate принципы, описанные в статье, и проблем с N+1 у вас не будет.
За @Data над сущностью в 2025 году могут выгнать с работы
Предлагаете руками писать @ToString, @EqualsAndHashCode, @Getter @Setter и @RequiredArgsConstructor ?
Или в чем проблема @Data на ваш взгляд?
https://habr.com/ru/companies/haulmont/articles/564682/ Вот здесь описывалось
Для ленивых: расчёт hashCode вызывает получение полей из БД для Entity
Забавно, никогда не использовал @Data, в первый раз решил, что можно заюзать ее для уменьшения кода и такой конфуз вышел) если это отвлекает, от сути статьи видимо следует заменить.
Hibernate, JPA, N+1 и лишние запросы в БД