❌ Как я память искал (Часть II)

В предыдущей части мы рассмотрели составные части возникновения проблемы.

А теперь давайте рассмотрим, как решить данный кейс и как не попасть в подобную ловушку неочевидного поведения Hibernate.

Решения 🤓

🟡Первое и самое очевидное:

Избегать fetch join при пагинации в Hibernate

Да так просто.

Но вы скажете: "А как же проблема N+1"? Ее я предлагаю решить всем известной аннотацией @BatchSize.

@Entity
public class User {
    //стандартные поля
    @OneToMany(mappedBy = "owner")
    @BatchSize(size = 50)
    private List<Car> cars = new ArrayList<>();
}
Количество запросов существенно уменьшится — на тот размер size, который мы задали. Это значит, что проблема N+1 решена.

Да, запросов станет точно больше чем 1. Но такова цена использования Spring Hibernate 🤷‍♀️

🟡Второе и не очень хорошее, а при увеличении количества связанных сущностей в запросе - опасное:

разделение запроса на две части с использованием @EntityGraph

@EntityGraph(attributePaths = {"cars"})
Page<User> findAll(Pageable pageable);

При таком решении в первой части запроса мы запрашиваем id наших User с определенной страницы. А во второй части запроса с помощью @EntityGraph и JOIN мы получаем все Car которые им принадлежат.

Но как показали тестовые запуски с использованием @EntityGraph над множеством связанных сущностей в основной, проведенные автором статьи(спасибо ему) :

"При пяти загружаемых коллекциях производительность разделенного запроса с @EntityGraph хуже в 2 раза. При десяти — в 45 раз. А при загрузке 15 коллекций — в 1401 раз! На графике нет данных по разделенному запросу для 20 коллекций, так как я просто-напросто получил ошибку OutOfMemoryError."

С @BatchSize же никаких JOIN не происходит, и при добавлении дополнительной коллекции с ассоциацией @OneToMany просто добавляются дополнительные select для этой коллекции.

🟡И третье, элементарное как свет солнца 😏

Использовать Нативный SQL - запрос.

Да, больше мороки с формированием динамического SQL (если у тебя 10 разных фильтров, ты сам будешь собирать SQL строку).

@Query(value = """
    SELECT u.id AS userId, u.name AS userName, c.model AS carModel
    FROM user u
    LEFT JOIN car c ON c.owner_id = u.id
    WHERE (:name IS NULL OR u.name ILIKE %:name%)
    ORDER BY 
        CASE WHEN :sortBy = 'name' THEN u.name
             WHEN :sortBy = 'id' THEN CAST(u.id AS TEXT)
             ELSE u.name
        END ASC
    LIMIT :limit OFFSET :offset
""", nativeQuery = true)
List<UserCarDTO> findWithFilters(
    @Param("name") String name,
    @Param("sortBy") String sortBy,
    @Param("limit") int limit,
    @Param("offset") int offset
);

Да, придется использовать дополнительный count-запрос: SELECT COUNT(*) , для обеспечения пагинации

@Query(value = """
    SELECT COUNT(DISTINCT u.id)
    FROM user u
    WHERE (:name IS NULL OR u.name ILIKE %:name%)
""", nativeQuery = true)
long countUsers(@Param("name") String name);

но, ты сам полностью управляешь процессом и скорее всего не встретишь неочевидного поведения 💪

➕ И на сладкое

Какие ещё конструкции в JPA/Hibernate могут привести к аналогичным проблемам, когда ты используешь fetch join и неожиданно получаешь избыточную загрузку в память, ломающую пагинацию или вызывающую дублирование/нагрузку?

1. Pageable + @Query (с JPQL) и JOIN FETCH
Даже если ты не используешь Specification, а пишешь JPQL с @Query, проблема остаётся.

2. EntityManager + JPQL с fetch и пагинацией
Даже ручной вызов через EntityManager может привести к тому же эффекту.

3. Criteria API с fetch + .setMaxResults()/.setFirstResult()
Даже если ты используешь чистый JPA Criteria API, проблема может проявиться.

4. Spring Data REST + @RepositoryRestResource + fetch join
Если ты используешь Spring Data REST, и в репозитории включён fetch join, например через @Query, то Spring сам применяет Pageable, и может попасть в эту ловушку. Опять же — всё сломается.


И личный совет: изучайте матчасть! Читайте наш канал и шанс, что Ваш прод упадет - существенно снизится!

Понравился стиль подачи материала?

Отправь другу и ставь - 🔥

#Java #fetch #autor

Чем отличается HashSet от TreeSet? 🤓

Ответ:

HashSet хранит элементы в хэш-таблице, не упорядочивает их, но работает быстрее (O(1) для добавления/поиска).

TreeSet хранит элементы в
отсортированном виде (на основе красно-черного дерева), но операции медленнее (O(log n)).

#собеседование

📌 Факт дня:

А вы знали, что первый "онлайн-банк" появился в 1995 году?

Security First Network Bank (SFNB), запущенный в 1995 году, был первым банком, предоставляющим услуги через интернет. Однако он потерпел неудачу из-за низкого доверия к подобным сервисам со стороны клиентов, которые были не готовы к таким инновациям. Другие ранние попытки создания онлайн-банкинга, такие как Chemical Bank и Chase Manhattan Bank, также показывали ограниченный успех, но заложили основу для последующего развития онлайн-банкинга. Позже другие банки, такие как Bank of America, стали успешными в этой области, что привело к широко распространенному внедрению онлайн-банкинга.

Proof

#facts

📌 Цитата дня: Дуглас Крокфорд

"Социальные сети — это не технология, это психология."

Крис Сакка, инвестор Twitter, сказал это в 2010 году на конференции TechCrunch.

Почитать короткую биографию

#Citation #Biography

Продолжаем выбирать темы для разбора и голосовать за рассмотрение предложенных! 🤓

Голосуем за тему к рассмотрению в эти выходные!

Выбираем новую тему!
(можете предложить что-то из того что предлагали на прошлой неделе и что проигрывает в голосовании!)

Не стесняемся! ✌️

В чем разница между throw и throws? 🤓

Ответ:

throw используется для явного выброса исключения, например: throw new IOException();.

throws указывается в сигнатуре метода, чтобы сообщить, какие проверяемые исключения он может выбросить, например: void method() throws IOException.

#собеседование

С 24.05 по 31.05
Предыдущий пост(с 17.05 по 23.05)
Следующая неделя

Воскресный мотивационный пост:
"Твой первый проект — важнее, чем думаешь"

Выбранная голосованием тема:
Паттерны проектирования на Java: суть, история и применение

Запись встреч:
Изучаем Swagger

Обучающие статьи:
Глубокое изучение типа данных double в Java
Глубокое изучение типа float в Java
Глубокое изучение типа данных char в Java

Введение в Liquibase
Структура и основные команды Liquibase

Пост под которым нет поздравлений:
Сегодня каналу исполнился год! 🥳

Авторские статьи:
Как я память искал (Часть I)
Как я память искал (Часть II)

Полезные статьи и видео:
Управление транзакциями в Spring: подробно о @Transactional
Делаем свою простейшую систему сборки для Java

Проблема N+1 в Hibernate — ВСЕ СПОСОБЫ решения

Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование

#memory

После проведенного голосования, определилась тема для рассмотрения в выходные - MVC.

Приступим'с

Архитектурный шаблон MVC в Java Spring: теория, правила, ошибки

MVC (Model–View–Controller) — это один из фундаментальных архитектурных паттернов в программной инженерии, направленный на разделение приложения на логически независимые компоненты. Его основная цель — изолировать пользовательский интерфейс от бизнес-логики и доступа к данным. В экосистеме Java фреймворк Spring реализует этот шаблон через модуль Spring MVC.

Теория: что такое MVC

Шаблон MVC подразумевает разделение приложения на три слоя:

Model (Модель)

Модель инкапсулирует бизнес-логику и данные приложения. Она может включать:
Сущности базы данных (например, классы с аннотацией @Entity).
Репозитории (@Repository), обеспечивающие доступ к данным.
Сервисный слой (@Service), реализующий бизнес-логику.
DTO (Data Transfer Objects) — объекты для обмена данными между слоями.

❗️Модель не должна зависеть от представления или контроллера.

View (Представление)

Представление отвечает за отображение информации пользователю. В Spring это обычно:
HTML-шаблоны (например, на Thymeleaf).
JSON-ответы (в случае REST API).
Альтернативные форматы (XML, PDF и пр.).
View должен быть как можно более простым и не содержать бизнес-логики.

Controller (Контроллер)

Контроллер — связующее звено между внешним миром (HTTP-запросами) и внутренними слоями приложения. Он:
Принимает входные данные.
Делегирует выполнение модели.
Выбирает и возвращает подходящее представление.
Контроллеры в Spring создаются с помощью аннотаций @Controller или @RestController.

Жизненный цикл HTTP-запроса в Spring MVC

🔵Пользователь отправляет HTTP-запрос.
🔵DispatcherServlet перехватывает запрос.
🔵Система HandlerMapping находит соответствующий контроллер.
🔵Контроллер вызывает метод бизнес-логики через @Service.
🔵Сервис взаимодействует с репозиториями и возвращает результат.
🔵Контроллер передаёт данные во View (или сериализует их в JSON).
🔵Ответ возвращается клиенту.

Роль слоёв в приложении Spring

Контроллер
Контроллер должен быть «тонким» и не содержать бизнес-логики. Его задача — маршрутизировать запросы и собирать данные, необходимые представлению.

Пример (корректный):

@GetMapping("/users")
public List<UserDto> getUsers(Model model) {
    return userService.getAllUsers();
}

Неправильный пример (контроллер содержит логику):

@GetMapping("/users")
public List<UserDto> getUsers(Model model) {
    List<User> users = userRepository.findAll();
    return users.stream()
        .map(user -> new UserDto(user.getId(), user.getName()))
        .collect(Collectors.toList());
}

Сервисный слой

Сервисный слой содержит бизнес-логику, правила обработки данных, валидацию, логи, обработку ошибок. Он изолирован от HTTP и представления. Сервисы не должны напрямую зависеть от Model, HttpServletRequest или аннотаций Spring MVC.

Пример:

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    public List<UserDto> getAllUsers() {
        return userRepository.findAll().stream()
            .map(user -> new UserDto(user.getId(), user.getName()))
            .collect(Collectors.toList());
    }
}

Репозиторий

Репозиторий отвечает за доступ к данным. Он инкапсулирует работу с базой и предоставляет CRUD-интерфейс.

public interface UserRepository extends JpaRepository<User, Long> {}

#Java #для_новичков #beginner #on_request #mvc

Мой сервис стучится в соседнее API 🧑‍💻😂

https://t.me/Java_for_beginner_dev

#Mems

Всем привет! ✌️

Приглашаю всех желающих сегодня собраться в Яндекс.Телемост в 16:00 по МСК!

В этот раз, @rKiraLis39 расскажет и покажет много интересного по многопоточке.

И даже если раньше вы все это знали, лишним повторить не будет.

Приходите, это хороший шанс позадавать вопросы 🧑‍💻

Как всегда жду всех! 🫡

«Ты не программируешь — ты притворяешься, что учишься»

Однажды я купил себе книгу Spring 5.
Большая, толстая, со множеством, страниц. Неся её домой я живо представлял себе, что уже завтра буду писать Spring-приложения, направо и налево. 🥳

И я честно прочитал ее. А потом еще разок. 🤓

И ПОНЯЛ, ЧТО НИЧЕГО НЕ ПОНЯЛ!

Точнее понять то понял (книга ж на русском 🤪), да вот открыв IDEA яснее мне ничего не стало.

Как это начать писать то? 😔

И вот тут, друзья, скрывается одна из потаённых реальностей обучения:

99% "учеников" не учатся. Они просто создают иллюзию прогресса: читают, смотрят, копят курсы — но не пишут код.

🚨 Пойми:

🔵Купить и прочитать хорошие книги ≠ уметь программировать.

Пока ты не сел и не написал — ты не учишься.

🔵 Смотреть популярные видео с каналов по программированию ≠ учить Java.

Тебе приятно, когда ты "в теме" — но это ложное ощущение движения.

🔵 Количество открытых вкладок в браузере с умными статьями ≠ умный ты.

Чтение статей создаёт видимость прогресса, но мозг это не фиксирует как навык.

🔵 Пока ты изображаешь, другие сдают тестовые и получают офферы.

Для тебя это должна быть не мотивация, а ультиматум: начни делать или отойди в сторону.

🔵 Месяц «обучения без практики» = 0% роста = потерянное время.

Притворяться — удобно. Но дорого

✔️ Поэтому прямо сейчас:

➡️ Закрой вкладку с курсами. Открой IDE. 🧑‍💻
➡️ Придумай и напиши что-то ужасное. (И пусть оно не работает. Но ты хотя бы начал). 😈
➡️ И да, будет больно. Будет стыдно (если никому не показывать, то не очень - только перед собой)😭
➡️Но это единственный путь, на котором ты реально сдвинешься с мёртвой точки. 💪


А я, все таки победил Spring.
Правда потом, книгу почти не открывал, только для уточнения совсем уж непонятных деталей.

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

Поэтому

Просто
Начни
ПИСАТЬ КОД

😎

#motivation

Предлагаем темы для разбора и публикации! 📖

В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.

Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.

Примерные правила:
🟢 темы, не выше уровня middle, чтоб был интерес общим.
🟢 один человек - одна тема.
🟢Тема должна быть отдельным теоретически-практическим вопросом. Готовый проект - это не тема!

Жду Ваших предложений! 👏