Hibernate

• Стейтмент предоставляет защиту от SQL-инъекций.  

• Стейтмент не просто бесполезен, а является мощным инструментом.  

• Необходимо реализовывать механизмы защиты самостоятельно.  

• ORM преобразует данные из объектно-ориентированного программирования в реляционные базы данных и наоборот.  

• Hibernate реализует концепцию ORM, позволяя получать полноценные объекты из таблиц.  

• Hibernate позволяет работать с объектно-ориентированными языками и реляционными базами данных.  

• JPA описывает систему управления объектами в реляционных базах данных.  

• Hibernate — это ORM-фреймворк, который появился до JPA.  

• JPA — это стандартная спецификация, разработанная Oracle.  

• JPA предоставляет интерфейсы для работы с объектами в реляционных базах данных.  

• Hibernate — это реализация JPA, которая позволяет работать с объектно-ориентированными языками.  

• Hibernate предоставляет возможность работы с нереляционными моделями данных.  

• JPA включает интерфейсы для работы с сессиями, подключениями и транзакциями.  

• Hibernate расширяет интерфейс Session и предоставляет пул подключений.  

• JPA позволяет работать с объектно-ориентированными языками вместо SQL.  

• Методы Hibernate включают persist, trim, detach, merge, update, flush, get, load, find.  

• persist помещает сущность в кэш первого уровня.  

• trim удаляет сущность из контекста.  

• detach перемещает сущность из контекста.  

• merge возвращает сущность в состояние persist.  

• update обновляет состояние сущности.  

• flush синхронизирует контекст с базой данных.  

• get, load и find получают сущности из базы данных.  

• lock блокирует сущность.  

• EntityManager и Session имеют разные методы, но выполняют схожие функции.  

• Методы EntityManager включают persist, remove, delete, get, и другие.  

• Session Manager имеет больше методов, но они могут быть заменены методами EntityManager.  

• persist возвращает объект, а save возвращает первичный ключ.  

• Методы persist и save выполняют разные функции, несмотря на схожесть названий.  

• EntityManager имеет меньше методов, но их достаточно для большинства задач.  

• Сущность в Hibernate представляет таблицу в базе данных.  

• Обязательные аннотации: @Entity, @Id, @GeneratedValue, @Column, @NotNull.  

• Hibernate менее требователен к сущностям, чем JPA, но имеет свои особенности.  

• Сущности должны иметь конструктор без параметров и геттеры.  

• Первичный ключ должен реализовывать интерфейс Serializable.  

• Сущности могут быть абстрактными классами, но не интерфейсами или перечислениями.  

• Сущности не могут быть вложенными классами.  

• Встраиваемые классы MBD не являются сущностями, а просто полями.  

• Аннотация @Embeddable не обязательна, но может быть полезна для переопределения атрибутов.  

• Если в сущности два встраиваемых класса, могут возникнуть проблемы с атрибутами.  

• Аннотация @Override используется для переопределения значений атрибутов.  

• Это позволяет избежать дублирования данных в таблице и обеспечивает уникальность значений.  

• Обсуждение различий между ассоциациями и ассоциациямиша.  

• Упоминание о переопределении ассоциаций на уровне объекта.  

• Решение не использовать ассоциацииша.  

• Объяснение, что суперклассы не являются сущностями.  

• Использование суперклассов для наследования общих полей и методов.  

• Нарушение принципа единственной ответственности при наличии логики в сущности.  

• Создание класса с аннотацией @MappedSuperClass.  

• Наследование от суперкласса через аннотацию или наследование.  

• Вопросы о наличии таблицы у суперкласса и его отношениях с другими сущностями.  

• Различия между @MappedSuperClass и @Embeddable.  

• Ограничения на использование суперклассов в операциях и запросах.  

• Поддержка полиморфных запросов и наследование на уровне приложения.  

• Три стратегии наследования: single table, table per class, join table.  

• Описание каждой стратегии и их влияние на производительность и нормализацию базы данных.  

• Поддержка приморских запросов в разных стратегиях.  

• Полиморфные запросы работают нормально, но сингл тейбл и джонни тейбл более производительны.  

• Соединение таблиц с помощью джойнов может быть затратным, поэтому по умолчанию используется сингл тейбл.  

• Наследование таблиц в реляционной модели не поддерживается, поэтому используются дополнительные инструменты или наследование внутри классов.  

• Стратегии наследования могут использоваться для мапинга динамов.  

• Для мапинга динамов используются аннотации, такие как стринг и орденов.  

• Стринг используется для строк, орденов для чисел.  

• Постлот и приперсист используются для логики, которая выполняется после сохранения или выборки данных.  

• Конвертер позволяет конвертировать значения динамов в строки или числа, но требует дополнительного кода.  

• Стринг и конвертер являются наиболее часто используемыми вариантами мапинга динамов.  

• Конвертеры позволяют устанавливать строки фиксированной длины.  

• Это снижает нагрузку на базу данных, особенно при большом количестве записей.  

• Конвертеры помогают управлять динамическими данными.  

• Использование Java Time для работы с датами.  

• Java Time обеспечивает точность и удобство работы с датами в разных часовых поясах.  

• Важно понимать, как мапить даты из базы данных и обратно.  

• Использование аннотации @ElementCollection для создания коллекций примитивных типов.  

• Коллекции записываются в отдельную таблицу, что снижает производительность.  

• Важно учитывать порядок данных и использовать аннотации для переопределения поведения.  

• Отношения между таблицами могут быть однонаправленными или двунаправленными.  

• Однонаправленные отношения позволяют одной таблице знать о другой, но не наоборот.  

• Двунаправленные отношения позволяют обеим таблицам знать друг о друге.  

• Каскады бывают разных типов, включая каскадное удаление и каскадное обновление.  

• Важно понимать, какие каскады использовать в зависимости от ситуации.  

• Каскады могут влиять на производительность и целостность данных.  

• Аннотация JoinColumn используется для указания владельца отношений в двунаправленных связях.  

• Без JoinColumn создается дополнительная таблица для хранения отношений, что снижает производительность.  

• JoinColumn указывает, какая сущность является владельцем связи.  

• JoinColumn применяется только при однонаправленных связях.  

• В двунаправленных связях JoinColumn обязателен для предотвращения создания дополнительных таблиц.  

• В случае связи ManyToMany владелец связи всегда определяется как Many.  

• В однонаправленных связях JoinColumn не обязателен, если не нужно переопределять значения полей.  

• В двунаправленных связях JoinColumn необходим для предотвращения создания дополнительных таблиц.  

• В связи ManyToMany владелец связи определяется автоматически.  

• Связь ManyToMany не рекомендуется использовать из-за проблем с производительностью и каскадами.  

• Неправильное использование каскадов может привести к удалению данных из обеих таблиц.  

• Рекомендуется использовать связь OneToMany для управления владельцами отношений.  

• Каскады включают удаление, обновление и сохранение данных.  

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

• Важно правильно настроить каскады для предотвращения ошибок.  

• Мягкое удаление удаляет сущности, на которые больше нет ссылок.  

• Используется для оптимизации и предотвращения удаления данных без необходимости.  

• Применяется в каскадах для удаления дочерних сущностей, на которые больше никто не ссылается.  

• Жадная загрузка данных не рекомендуется из-за проблем с производительностью.  

• Ленивая загрузка данных используется для оптимизации запросов.  

• Рекомендуется использовать ленивую загрузку для динамических прокси и гибернации.  

• Обсуждение проблемы "один плюс один" в Hibernate.  

• Матвиенко рекомендует использовать lazy loading для всех сущностей.  

• Lazy loading может ухудшить производительность из-за загрузки всех данных сразу.  

• Прокси создаются во время компиляции для оптимизации работы с сущностями.  

• Прокси используются для уменьшения обращений к базе данных.  

• Прокси могут быть созданы через наследование или интерфейсы.  

• Прокси могут вызывать исключения при отключении от базы данных.  

• Решение проблемы через использование антиграфа или join fetch.  

• Join fetch автоматически загружает все зависимые сущности при загрузке основной сущности.  

• Сущности проходят через несколько состояний: transient, persistent, detached, rehydrated.  

• При удалении объекта или закрытии сессии, сущность переходит в состояние detached.  

• При сохранении объекта в базу данных, он переходит в состояние persistent.  

• Традиент - это объект, который еще не находится под контролем антити менеджера.  

• Объект может находиться в нескольких состояниях, включая нью и персист.  

• Нью - это состояние, когда объект создан, но еще не был в контексте персистентности и не имеет первичного ключа.  

• Объект в состоянии нью не имеет первичного ключа и не был в контексте персистентности.  

• Метод персист присваивает первичный ключ объекту сразу после вызова.  

• Если объект не имеет первичного ключа, он не будет прикреплен к контексту персистентности.  

• Переход между состояниями возможен через методы персист и сейф.  

• Метод персист ничего не возвращает, а метод сейф возвращает объект.  

• Внутри транзакции состояние объектов может меняться, но изменения не всегда сохраняются в базе данных.  

• Метод мерч используется для обновления данных в транзакции.  

• Он создает копию объекта и позволяет изменять её, не затрагивая исходный объект.  

• Изменения, сделанные в копии, будут применены к базе данных.  

• Использование аннотации @Basic для настройки атрибутов сущности.  

• Возможность указания типа значения, например, байт вместо int.  

• Аннотации @Basic больше не выполняют особых функций и могут быть заменены другими методами.  

• Возможность ленивой загрузки полей с помощью аннотации @Basic.  

• Поле загружается только при обращении к нему, что может быть полезно для оптимизации.  

• Аннотации @Basic и @Access имеют дополнительные параметры, такие как @AccessType и @AccessLevel.  

• Аннотации для задания стратегий генерации ключей: @GeneratedValue, @Id, @SequenceGenerator.  

• @GeneratedValue позволяет БД управлять генерацией ключей.  

• @Id и @SequenceGenerator требуют ручного управления генерацией ключей.  

• Использование @SequenceGenerator для пакетной вставки.  

• @SequenceGenerator позволяет использовать последовательные значения для ключей.  

• Пакетная вставка с использованием @SequenceGenerator может привести к разрывам ключей при недостатке данных.  

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

• Тейбл требует ручного заполнения таблицы и блокировки для предотвращения конфликтов.  

• Это медленная и ненадежная стратегия, так как значения могут закончиться.  

• Hibernate позволяет устанавливать стратегии генерации ключей на уровне базы данных или таблицы.  

• Это позволяет использовать разные стратегии для разных таблиц и баз данных.  

• Hibernate может создавать и использовать свои стратегии генерации ключей.  

• В некоторых случаях ключи должны задаваться явно, а не генерироваться автоматически.  

• Это требует, чтобы разработчик сам поставлял ключи вместе с сущностью.  

• Такой подход используется для установки ключей вручную.  

• Order By используется для упорядочения элементов коллекции.  

• Order By Colum добавляет специальную колонку в таблицу для хранения порядка элементов коллекции.  

• Hibernate поддерживает шесть видов блокировок, начиная с общедоступных и заканчивая закрытыми.  

• Оптимистичные блокировки основаны на версионности и позволяют проверять изменения полей в конце транзакции.  

• Оптимистичный форс инкремент увеличивает поле версионности при чтении и изменении, что может привести к исключениям при конфликтах.  

• Оптимистичный форс инкремент увеличивает поле версионности при чтении и изменении, независимо от того, были ли внесены изменения в сущность.  

• Это может привести к исключениям, если другие транзакции пытаются изменить поле до завершения текущей транзакции.  

• В отличие от обычной оптимистической блокировки, форс инкремент увеличивает поле версионности даже при чтении, что может вызвать конфликты.  

• Оптимистическая блокировка происходит на уровне сервиса, а не базы данных.  

• Пессимистическая блокировка работает на уровне базы данных и требует дополнительных команд.  

• Пессимистическая блокировка блокирует как чтение, так и запись, что делает её более жесткой.  

• Пессимистическая блокировка с инкрементом работает аналогично фо апдейт, но также использует версионность.  

• Пессимистические блокировки требуют синхронного выполнения всех изменений и не допускают конфликтов.  

• Оптимистические блокировки позволяют разгрузить базу данных, блокируя строки на уровне приложения.  

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

• Использование хранимых процедур и временных таблиц может снизить нагрузку на базу данных.  

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

• Hibernate поддерживает кэш первого уровня на уровне сессии.  

• Кэш второго уровня можно реализовать через сторонних провайдеров, таких как Redis.  

• Стратегии кэширования включают read-only, read-write, strict-write и transactional.  

• Кэширование второго уровня требует особого опыта и настроек.  

• Важно понимать, когда и как использовать кэш второго уровня.  

• Сброс кэша должен происходить корректно, чтобы избежать проблем с памятью.  

• Кэш первого уровня устанавливается на сессию и работает внутри сессии.  

• Разделение на два вида скопов: транзакционный и сессионный.  

• Персистентный контекст создается в рамках одной транзакции или сессии.  

• Обсуждение работы кэша первого уровня.  

• Рекомендация библиотеки CoffeeCache для реализации кэша второго уровня.  

• Библиотека CoffeeCache проста в использовании и имеет 13,5 тысяч звезд на GitHub.  

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

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

• Рекомендуется использовать коннектор для подключения реализаций кэша второго уровня.  

• Использование аннотаций IDClass и MBDID для маппинга составного ключа.  

• IDClass создает отдельный класс для полей составного ключа.  

• MBDID использует встраиваемый объект для полей составного ключа.  

• Решение проблемы "один плюс один" через использование аннотаций или метода @OneToOne.  

• Использование аннотаций для создания интеграций.  

• Интеграции могут быть созданы через аннотации или метод @OneToOne.  

• Интеграции решают проблему "один плюс один" для сущностей до 22 уровней вложенности.  

• Интеграции работают лучше, чем джейн фетчи для больших иерархий сущностей.  

• Интеграции позволяют автоматически загружать связанные сущности без необходимости написания нативных запросов.  

• Критерии используют параметр fetch, как и в KQL, но с другим синтаксисом.  

• Динамические запросы с критериями могут быть массивными и удобными, но редко являются оптимальным вариантом.  

• Альтернатива критериям - JPA, который рекомендуется для сложных запросов.  

• JPA позволяет использовать Java-код для запросов, что делает его мощным, но сложным инструментом.  

• JPA может порождать проблемы при неверной интерпретации запросов.  

• В сложных запросах лучше использовать Spring Data JPA, чем Hibernate.  

• Обсуждение многопоточности и её эффективности.  

• Благодарности участникам и поздравления со сдачей.  

• Обсуждение вопросов, которые могут возникнуть на собеседованиях, и важность знания Hibernate.  

• Обсуждение паттернов и тактик в Spring.  

• Важность подготовки к Spring Data JPA и Spring Boot.  

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

• Обсуждение различных протоколов и их использования.  

• Благодарности и прощание.