Какие есть кэши в Hibernate и какие работают по умолчанию?
3 уровня кеширования:
• Кеш первого уровня (First-level cache). По умолчанию включен.
• Кеш второго уровня (Second-level cache). По умолчанию отключен.
• Кеш запросов (Query cache). По умолчанию отключен.
3 уровня кеширования:
• Кеш первого уровня (First-level cache). По умолчанию включен.
• Кеш второго уровня (Second-level cache). По умолчанию отключен.
• Кеш запросов (Query cache). По умолчанию отключен.
👍21
Чем отличается Lazy от Eager в Hibernate?
• Eager Loading — стратегия загрузки, при которой подгрузка связанных сущностей происходит сразу. Для применения необходимо в аннотацию отношения (@OneToOne, @ManyToOne, @OneToMany, @ManyToMany) передать fetch = FetchType.EAGER. Используется по умолчанию для отношений @OneToOne и @ManyToOne.
• Lazy Loading — стратегия загрузки, при которой подгрузка связанных сущностей откладывается как можно дольше. Чтобы задать такое поведение, нужно в аннотацию отношения (@OneToOne, @ManyToOne, @OneToMany, @ManyToMany) передать fetch = FetchType.LAZY. Используется по умолчанию для отношений @OneToMany, @ManyToMany. До момента загрузки используется proxy-объект, вместо реального. Если обратиться к такому LAZY-полю после закрытия сессии Hibernate, то получим LazyInitializationException.
• Eager Loading — стратегия загрузки, при которой подгрузка связанных сущностей происходит сразу. Для применения необходимо в аннотацию отношения (@OneToOne, @ManyToOne, @OneToMany, @ManyToMany) передать fetch = FetchType.EAGER. Используется по умолчанию для отношений @OneToOne и @ManyToOne.
• Lazy Loading — стратегия загрузки, при которой подгрузка связанных сущностей откладывается как можно дольше. Чтобы задать такое поведение, нужно в аннотацию отношения (@OneToOne, @ManyToOne, @OneToMany, @ManyToMany) передать fetch = FetchType.LAZY. Используется по умолчанию для отношений @OneToMany, @ManyToMany. До момента загрузки используется proxy-объект, вместо реального. Если обратиться к такому LAZY-полю после закрытия сессии Hibernate, то получим LazyInitializationException.
👍25
Что выведет следующий код?
Anonymous Quiz
30%
Произойдет ошибка компиляции
24%
Во время исполнения возникнет исключение NullPointerException
38%
null
8%
1
👍28😢4🥴3
Как описать составной ключ при использовании Hibernate?
На всякий случай: составной ключ — первичный ключ, состоящий из двух и более атрибутов.
Чтобы описать составной ключ при использовании Hibernate, нам необходимо создать под этот ключ отдельный класс с необходимыми полями и добавить ему аннотацию @Embeddable. Кроме того, он должен быть Serializable и иметь реализацию equals и hashcode.
В самой же сущности, для которой мы описываем составной ключ, добавляем поле только что созданного класса ключа и вешаем на него аннотацию @EmbeddedId.
На всякий случай: составной ключ — первичный ключ, состоящий из двух и более атрибутов.
Чтобы описать составной ключ при использовании Hibernate, нам необходимо создать под этот ключ отдельный класс с необходимыми полями и добавить ему аннотацию @Embeddable. Кроме того, он должен быть Serializable и иметь реализацию equals и hashcode.
В самой же сущности, для которой мы описываем составной ключ, добавляем поле только что созданного класса ключа и вешаем на него аннотацию @EmbeddedId.
👍28
👍26🤨10😢7🏆2🌚1
Как можно отобразить наследование на БД с помощью JPA (Hibernate)?
Есть 4 способа отобразить наследование на БД с помощью JPA (Hibernate):
• MappedSuperclass — поля родителя содержатся в каждой таблице для каждого дочернего класса. Базовый класс отдельной таблицы не имеет. На базовый класс навешиваем @MappedSuperClass, а вот на дочерние @Entity. Если в таблице потомка поле родителя называется не так, как указано в родительском классе, то его нужно смаппить с помощью аннотации @AttributeOverride в классе этого потомка. Родитель не может участвовать в ассоциации. При полиморфных запросах у нас будут отдельные запросы для каждой таблицы.
• Single table — вся иерархия классов в одной таблице. Чтобы различать классы, необходимо добавить колонку-дискриминатор. В данной стратегии на родительский @Entity-класс навешивается @Inheritance(strategy = InheritanceType.SINGLE_TABLE) и @DiscriminatorColumn(name = "YOUR_DISCRIMINATOR_COLUMN_NAME") (по умолчанию имя колонки DTYPE и тип VARCHAR). В каждом подклассе указываем @DiscriminatorValue("ThisChildName") со значением, которое будет храниться в колонке-дискриминаторе для данного класса. Если нет возможности добавить колонку, то можно использовать аннотацию @DiscriminatorFormula, в которой указать выражение CASE...WHEN — это не по JPA, фишка Hibernate. Денормализация. Простые запросы к одной таблице. Возможное нарушение целостности — столбцы подклассов могут содержать NULL.
• Joined table — отдельные таблицы для всех классов иерархии, включая родителя. В каждой таблице только свои поля, а в дочерних добавляется внешний (он же первичный) ключ для связи с родительской таблицей. В @Entity-класс родителя добавляем @Inheritance(strategy = InheritanceType.JOINED). Для полиморфных запросов используются JOIN, а также выражение CASE...WHEN, вычисляющее значение поля _clazz, которое заполняется литералами (0 (родитель), 1, 2 и т.д.) и помогает Hibernate определить какого класса будет экземпляр.
• Table per class — также как и в MappedSuperclass, имеем отдельные таблицы для каждого подкласса. Базовый класс отдельной таблицы не имеет. По спецификации JPA 2.2 данная стратегия является опциональной, но в Hibernate реализована, поэтому продолжим. В данном случае на базовый класс мы навешиваем @Entity и @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS). Поле первичного ключа (@Id) обязательно для родительского класса. Также аннотация @AttributeOverride в этой стратегии не работает — называйте родительские поля в таблицах сразу единообразно. Полиморфный запрос будет использовать UNION для объединения таблиц. Чтобы различить при создании экземпляров подклассы, Hibernate добавляет поле _clazz в запросы, содержащие литералы (1, 2 и т.д.). А одинаковый набор столбцов для объединения добирается как NULL AS some_field. Родитель может участвовать в ассоциации с другими сущностями.
Есть 4 способа отобразить наследование на БД с помощью JPA (Hibernate):
• MappedSuperclass — поля родителя содержатся в каждой таблице для каждого дочернего класса. Базовый класс отдельной таблицы не имеет. На базовый класс навешиваем @MappedSuperClass, а вот на дочерние @Entity. Если в таблице потомка поле родителя называется не так, как указано в родительском классе, то его нужно смаппить с помощью аннотации @AttributeOverride в классе этого потомка. Родитель не может участвовать в ассоциации. При полиморфных запросах у нас будут отдельные запросы для каждой таблицы.
• Single table — вся иерархия классов в одной таблице. Чтобы различать классы, необходимо добавить колонку-дискриминатор. В данной стратегии на родительский @Entity-класс навешивается @Inheritance(strategy = InheritanceType.SINGLE_TABLE) и @DiscriminatorColumn(name = "YOUR_DISCRIMINATOR_COLUMN_NAME") (по умолчанию имя колонки DTYPE и тип VARCHAR). В каждом подклассе указываем @DiscriminatorValue("ThisChildName") со значением, которое будет храниться в колонке-дискриминаторе для данного класса. Если нет возможности добавить колонку, то можно использовать аннотацию @DiscriminatorFormula, в которой указать выражение CASE...WHEN — это не по JPA, фишка Hibernate. Денормализация. Простые запросы к одной таблице. Возможное нарушение целостности — столбцы подклассов могут содержать NULL.
• Joined table — отдельные таблицы для всех классов иерархии, включая родителя. В каждой таблице только свои поля, а в дочерних добавляется внешний (он же первичный) ключ для связи с родительской таблицей. В @Entity-класс родителя добавляем @Inheritance(strategy = InheritanceType.JOINED). Для полиморфных запросов используются JOIN, а также выражение CASE...WHEN, вычисляющее значение поля _clazz, которое заполняется литералами (0 (родитель), 1, 2 и т.д.) и помогает Hibernate определить какого класса будет экземпляр.
• Table per class — также как и в MappedSuperclass, имеем отдельные таблицы для каждого подкласса. Базовый класс отдельной таблицы не имеет. По спецификации JPA 2.2 данная стратегия является опциональной, но в Hibernate реализована, поэтому продолжим. В данном случае на базовый класс мы навешиваем @Entity и @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS). Поле первичного ключа (@Id) обязательно для родительского класса. Также аннотация @AttributeOverride в этой стратегии не работает — называйте родительские поля в таблицах сразу единообразно. Полиморфный запрос будет использовать UNION для объединения таблиц. Чтобы различить при создании экземпляров подклассы, Hibernate добавляет поле _clazz в запросы, содержащие литералы (1, 2 и т.д.). А одинаковый набор столбцов для объединения добирается как NULL AS some_field. Родитель может участвовать в ассоциации с другими сущностями.
👍28
Какой метод экземпляра Iterator может бросить исключение NoSuchElementException?
Anonymous Quiz
5%
add()
50%
next()
30%
remove()
15%
hasNext()
🎄17👍15🌭1
Что такое coupling и cohesion? Что из них (или оба) должно быть сильным (высоким) и/или слабым (низким)?
Coupling (Зацепление) — степень зависимости между программными компонентами. Должна быть низкой.
Cohesion (Связность) — степень сфокусированности методов класса. Должна быть высокой.
Подробнее почитать и посмотреть картинки можно тут на русском.
Coupling (Зацепление) — степень зависимости между программными компонентами. Должна быть низкой.
Cohesion (Связность) — степень сфокусированности методов класса. Должна быть высокой.
Подробнее почитать и посмотреть картинки можно тут на русском.
👍25❤🔥3🌚2⚡1
Что выведет следующий код?
Anonymous Quiz
24%
NullPointerException
12%
ClassCastException
16%
Integer
47%
Код не скомпилируется
👍19🎄5
Что такое куб масштабирования?
Куб масштабирования (scale cube, из книги The Art of Scalability) является наглядным изображением трёх ортогональных способов увеличения производительности приложения: sharding, mirrorring и microservices.
• Sharding (data partioning) — разбиение и размещение однотипных данных по разным узлам.
• Mirroring (horizontal duplication) — дублирование или клонирование данных для уменьшения времени отклика.
• Microservices — архитектурный подход, при котором функциональность системы разбивается на отдельные сервисы по бизнес-задачам.
Куб масштабирования (scale cube, из книги The Art of Scalability) является наглядным изображением трёх ортогональных способов увеличения производительности приложения: sharding, mirrorring и microservices.
• Sharding (data partioning) — разбиение и размещение однотипных данных по разным узлам.
• Mirroring (horizontal duplication) — дублирование или клонирование данных для уменьшения времени отклика.
• Microservices — архитектурный подход, при котором функциональность системы разбивается на отдельные сервисы по бизнес-задачам.
👍18🔥3
В каких случаях использование TreeSetпредпочтительнее использования HashSet?
Anonymous Quiz
10%
Если требуется модифицировать производительность итератора по коллекции
9%
Если необходимо часто осуществлять обращение к элементу Set
12%
Если необходимо часто вставлять в Set новые элементы или удалять их
69%
Если нужно гарантировать сохранения порядка элементов коллекции
🔥22👍9
Чем сервисная архитектура отличается от микросервисной?
Сервис-ориентированная архитектура (SOA) — независимый от технологий, компаний и программных продуктов подход к разработке программного обеспечения на основе распределённых, слабосвязанных заменяемых компонентов с чётко определёнными интерфейсами и протоколами взаимодействия. Область охвата SOA — это всё предприятие, где происходит взаимодействие между приложениями. SOA делает ставку на доступ к бизнес-функциям предприятия через повторно используемые интерфейсы.
Сервис в данной архитектуре:
• представляет бизнес-логику с определённым результатом (много ответственностей, связанных единой бизнес-областью, целью, смыслом и т.п.);
• может состоять из других сервисов или зависеть от них;
• является "чёрным ящиком" для своих клиентов.
Как и все серьёзные подходы к чему-либо имеет свой манифест
Микросервисная архитектура (MSA) — частный случай SOA, побуждающий строить взаимодействие насколько это возможно и необходимо небольших, слабосвязанных, легко изменяемых и взаимозаменяемых компонентов (микросервисов). MSA ориентирована, в первую очередь, на структуру и компоненты отдельного приложения.
Микросервис:
• выполняет только одну достаточно элементарную и определённую функцию (Unix way — единственная ответственность);
• деплоится и разрабатывается независимо от других микросервисов;
• является независимым от других микросервисов (в том числе максимальная минимизация общего кода);
• является "чёрным ящиком" для своих клиентов.
Можно найти несколько источников, где MSA представляется как нечто новое и хорошее, а SOA — старое и умирающее. Часто это ещё и подаётся под соусом технологий. ИМХО — это больше маркетинговая туфта, чем хорошее сравнение. MSA и SOA не завязаны на технологии и не ограничивают в их использовании. Более того, оба подхода можно совмещать с пользой для бизнеса.
Сервис-ориентированная архитектура (SOA) — независимый от технологий, компаний и программных продуктов подход к разработке программного обеспечения на основе распределённых, слабосвязанных заменяемых компонентов с чётко определёнными интерфейсами и протоколами взаимодействия. Область охвата SOA — это всё предприятие, где происходит взаимодействие между приложениями. SOA делает ставку на доступ к бизнес-функциям предприятия через повторно используемые интерфейсы.
Сервис в данной архитектуре:
• представляет бизнес-логику с определённым результатом (много ответственностей, связанных единой бизнес-областью, целью, смыслом и т.п.);
• может состоять из других сервисов или зависеть от них;
• является "чёрным ящиком" для своих клиентов.
Как и все серьёзные подходы к чему-либо имеет свой манифест
Микросервисная архитектура (MSA) — частный случай SOA, побуждающий строить взаимодействие насколько это возможно и необходимо небольших, слабосвязанных, легко изменяемых и взаимозаменяемых компонентов (микросервисов). MSA ориентирована, в первую очередь, на структуру и компоненты отдельного приложения.
Микросервис:
• выполняет только одну достаточно элементарную и определённую функцию (Unix way — единственная ответственность);
• деплоится и разрабатывается независимо от других микросервисов;
• является независимым от других микросервисов (в том числе максимальная минимизация общего кода);
• является "чёрным ящиком" для своих клиентов.
Можно найти несколько источников, где MSA представляется как нечто новое и хорошее, а SOA — старое и умирающее. Часто это ещё и подаётся под соусом технологий. ИМХО — это больше маркетинговая туфта, чем хорошее сравнение. MSA и SOA не завязаны на технологии и не ограничивают в их использовании. Более того, оба подхода можно совмещать с пользой для бизнеса.
👍19🔥10❤1☃1
Какие исключения будут брошены методом main?
Anonymous Quiz
38%
IndexOutOfBoundsException
29%
Код не скомпилируется
21%
NullPointerException
12%
ClassCastException
👍16👌6🌭2
Какие есть ограничения у микросервисов? Назовите достоинства и недостатки микросервисной архитектуры
Достоинства:
• Меньше кода на программный компонент (микросервис) -> проще и быстрее разрабатывать, поддерживать, тестировать, понимать, выбросить и переписать, реализовывать с помощью наиболее подходящих технологий и инструментов (в том числе на новые)
• Меньше команда -> меньше проблем и конфликтов при мёрже и совместной разработке
• Проще горизонтально масштабировать
• Быстрее и проще как внедрять, так и откатывать
Недостатки:
• Увеличение накладных расходов на взаимодействие между программными компонентами (микросервисами) — обмен между ними выполняется по сети со всем вытекающим (сериализация/десериализация, задержки и т.д.)
• Возможно появление необходимости распределённых транзакций
• Увеличение объёмов логирования и мониторинга
• Дублирование кода
• Сложнее дебажить и отлавливать ошибки
• Нужно быть готовым и способным продолжить работать, когда любой из микросервисов отвалится
• Общая сложность растёт с количеством микросервисов
Достоинства:
• Меньше кода на программный компонент (микросервис) -> проще и быстрее разрабатывать, поддерживать, тестировать, понимать, выбросить и переписать, реализовывать с помощью наиболее подходящих технологий и инструментов (в том числе на новые)
• Меньше команда -> меньше проблем и конфликтов при мёрже и совместной разработке
• Проще горизонтально масштабировать
• Быстрее и проще как внедрять, так и откатывать
Недостатки:
• Увеличение накладных расходов на взаимодействие между программными компонентами (микросервисами) — обмен между ними выполняется по сети со всем вытекающим (сериализация/десериализация, задержки и т.д.)
• Возможно появление необходимости распределённых транзакций
• Увеличение объёмов логирования и мониторинга
• Дублирование кода
• Сложнее дебажить и отлавливать ошибки
• Нужно быть готовым и способным продолжить работать, когда любой из микросервисов отвалится
• Общая сложность растёт с количеством микросервисов
👍38🤔2
Что выведет следующий код?
Anonymous Quiz
17%
Exception
22%
ArithmeticExceptionFinally
29%
Код не скомпилируется
31%
ExceptionFinally
🌚12👍8🏆3🌭2
Чем композиция отличается от агрегации?
Композиция (composition) — отношение "является частью" (HAS-A Relationship), при котором целое явно контролирует время жизни своей составной части.
Агрегация (aggregation) — отношение "является частью" (HAS-A Relationship), при котором целое хоть и содержит свою составную часть, время их жизни не связано.
Композиция (composition) — отношение "является частью" (HAS-A Relationship), при котором целое явно контролирует время жизни своей составной части.
Агрегация (aggregation) — отношение "является частью" (HAS-A Relationship), при котором целое хоть и содержит свою составную часть, время их жизни не связано.
👍27🤯4🤔3❤🔥1🤣1