Прочитал книгу "От Джуна до Сеньора. Как стать востребованным разработчиком", автор - Владимир Швец.

Увидел ее в книжном, она небольшая (211 страниц), заинтересовало то, как человек будет описывать свой 15-летний опыт, сравнить его со своим почти уже 5-летним опытом.

Книга мне понравилась, читается быстро и легко, как обзор и повторение ключевых моментов в разработке как с технической стороны, так и со стороны взаимодействия с людьми и отношению к работе, не смотря на то, что некоторые вещи очевидные.

Книга разделена на 3 основные секции (1. Код 2. Люди 3. Я). Читать можно в любом порядке, то что будет интересно.

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

Для меня здесь было интересно повторить в очередной раз о теме перфекционизма, например не рефакторить код 3 недели вместо того чтобы добавлять приоритетный функционал, уметь останавливать себя не смотря на тягу к красивому коду.
Различать программирование для себя и для работы не смотря на тягу попробовать новые технологии или обновиться до новой версии фреймворка или языка.

Помимо этого можно еще упомянуть следующие моменты:
— О здравом подходе к абстракциям в коде (KISS).
— Об отделении себя как личности от результатов твоей работы, например, при ревью кода не нужно воспринимать комментарии как личное оскорбление тебя как человека, можно рассматривать код как инструмент к достижению общей цели и у каждого участника команды общий интерес чтобы все работало как нужно. Конечно тут зависит еще от людей и их характеров, но мысль правильная.

Найти книгу достаточно просто, может кому-то будет интересно как и мне для повторения и сравнения опыта, а может кто-то узнает что-то новое.

#note #sources #book_review

➿ Меню
➿ Подпишись: @developer_sandbox

После обсуждения предыдущего поста, решил составить список книг.

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

То что подойдет начинающим помечено 🐣.

Перейдем к списку:

📚 Java:
- 🐣 Core Java Volume I--Fundamentals (Core Series) 11th Edition - Cay Horstmann
- 🐣 Thinking in Java - Bruce Eckel
- 🐣 Java: The Complete Reference - Herbert Schildt
- 🐣 Head First Java: A Brain-Friendly Guide - Kathy Sierra, Bert Bates, Trisha Gee
- 📖 Effective Java, 3rd Edition - Joshua Bloch
- 📖 Java Puzzlers: Traps, Pitfalls, and Corner Cases - Joshua Bloch, Neal Gafter
- 📖 Java Concurrency in Practice - Brian Goetz

📚 Алгоритмы и структуры данных:
- 🐣 Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People - Aditya Bhargava
- 📖 Algorithms - Robert Sedgewick
- 📖 Introduction to Algorithms - Thomas H. Cormen

📚 Архитектура и системный дизайн:
- 📖 Clean Architecture: A Craftsman's Guide to Software Structure and Design - Robert C. Martin
- 📖 System Design Interview – An insider's guide - Alex Xu
- 📖 Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems - Martin Kleppmann
- 📖 Building Microservices: Designing Fine-Grained Systems - Sam Newman

📚 Паттерны проектирования:
- 📖 Design Patterns: Elements of Reusable Object-Oriented Software - Gamma Erich, Helm Richard, Johnson Ralph, Vlissides John
- 📖 Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software - Eric Freeman, Elisabeth Robson
- 📖 Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions - Gregor Hohpe, Bobby Woolf

📚 SQL:
- 🐣 Learn SQL The Hard Way - Zed Shaw

📚 Computer science:
- 🐣 Code: The Hidden Language of Computer Hardware and Software - Charles Petzold
- 🐣 Computer Science Distilled: Learn the Art of Solving Computational Problems - Wladston Ferreira Filho

📚 Разработка:
- 📖 Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin
- 📖 Refactoring: Improving the Design of Existing Code - Martin Fowler
- 📖 Code Complete: A Practical Handbook of Software Construction - Steve McConnell
- 📖 Working Effectively with Legacy Code - Michael Feathers
- 📖 The Pragmatic Programmer: Your Journey To Mastery - David Thomas, Andrew Hunt
- 📖 Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans
- 📖 Cracking the Coding Interview: 189 Programming Questions and Solutions - Gayle Laakmann McDowell
- 📖 Test Driven Development: By Example - Kent Beck

Буду рад, если в комментариях вы напишете, с какими еще книгами следует ознакомиться 📚

#note #sources

➿ Меню
➿ Подпишись: @developer_sandbox

❓ Что такое DLT и как это реализовать в Apache Kafka?

DLT (Dead Letter Topic) или DLC (Dead Letter Channel) или DLQ (Dead Letter Queue) — это подход для обработки недоставленных сообщений, которые не удалось обработать в нормальном режиме.

Представим, что идет поток сообщений через Apache Kafka. Producer их посылает, Consumer их принимает.

При обработке Consumer'ом сообщений, может возникнуть исключение, по самым разным причинам, например, неправильный формат данных, NPE, неправильное значение определенного поля в сообщении и т.д. И нам необходимо определить поведение для таких ситуаций. И одним из способов является DLT.

Выбираем топик, для которого мы хотим обрабатывать ошибки, например, demo-topic. Создаем дополнительный топик для сообщений с ошибками, например, demo-topic.failures.
Когда Consumer будет получать исключение в ходе обработки сообщения, он будет отправлять это сообщение в demo-topic.failures с дополнительной информацией в Headers о том, какое исключение было выброшено.

Помимо этого, можно реализовать несколько попыток повторной отправки сообщения, прежде чем оно все-таки попадет в DLT. В Spring это уже все реализовано, остается только правильно сконфигурировать.

❓ Какие преимущества дает такой подход?
— Отделение основного потока сообщений, от потока ошибок
— Можно настроить удобный мониторинг для разных типов исключений
— Можно хранить ошибки дольше и более подробно исследовать их причины
— Можно вручную исправить ошибку и переотправить сообщение из demo-topic.failures

❓ Когда не стоит использовать такой подход и в чем его минусы?
— Усложнение архитектуры. Если исключения возникают редко, и вы можете их обработать более простым способом, можно не усложнять.
— Не стоит использовать DLT для проблем с соединением Consumer'a с другими системами. Это ответственность приложения consumer'a.
— Дополнительная нагрузка на сеть и дополнительное место для хранения ошибок в отдельном топике.

Практика:
— Добавил удобную возможность посылать сообщения, которые вызывают ошибки через Spring Shell.
— Добавил механизм ретраев через ExponentialBackOffWithMaxRetries и интеграционный тест с помощью testcontainers, который проверяет как работает DLT.

Все это по ссылке — 🐙Github

#sandbox_kafka #spring_boot_kafka

➿ Меню
➿ Подпишись: @developer_sandbox

❓ Что такое SSL сертификаты и для чего они нужны?

Рассмотрим на примере:
У нас есть сайт, где клиент вводит персональные данные (например, данные банковских карточек, паспорта, номера телефонов и т.д.)

Если мы используем на сайте HTTP протокол, то получаем следующие проблемы:
❌ Персональные данные передаются по сети в открытом виде как обычный текст, и злоумышленник, имеющий доступ к сети, может эти данные получить либо изменить.
❌ Поисковики (google и др.) понижают в результатах поиска сайты, использующие HTTP
❌ Браузеры (google chrome и др.) перед переходом на HTTP сайт показывают предупреждение, что он небезопасный
❌ Нет доказательства что наш сайт, принадлежит нашей организации. Т.е. нету сертификата, в котором это прописано. И злоумышленники могут создавать копии нашего сайта.

Для решения этих проблем, нам необходимо перейти на HTTPS. И здесь мы вводим понятия SSL и TLS:
SSL — Secure Sockets Layer — протокол в криптографии для безопасной передачи данных по сети.
SSL является устаревшим и вместо него используется разработанный на его основе TLS — Transport Layer Security, однако терминология часто встречается из старого протокола, и когда говорят SSL сертификат, имеют ввиду TLS сертификат.

HTTPS использует TLS для обеспечения безопасной передачи данных. Фактически HTTPS это HTTP, который использует уровнем ниже TLS.

Благодаря использованию TLS мы получаем:
✅ Конфиденциальность — данные передаются по сети в зашифрованном виде, теперь злоумышленник не увидит наши персональные данные как обычный текст.
✅ Подлинность — в сертификате нашего сайта будет связь между ним и нашей организацией. Перед отправкой данных, клиент проверит сертификат и сможет убедиться, что он попал на оригинальный сайт.
✅ Целостность — данные гарантированно будут получены клиентом/сервером в том виде, в котором они были отправлены клиентом/сервером. Злоумышленник не сможет изменить данные если он их перехватит. (Достигается это благодаря вычислению MAC (Message Authentication Code). Клиент вычисляет хеш сообщения и передает его серверу вместе с сообщением, сервер вычисляет хеш полученного сообщения и сравнивает с хешом полученным от клиента. Если хеш совпадает, значит сообщение не было изменено.)

Сама реализация протокола TLS требует наличие сертификата. Без него работать не будет.

SSL (TLS) сертификат — логически представляет собой цифровой паспорт сервера, а физически это файл, обычно с расширением .cer или .pem

В нем содержится следующая основная информация:
📝 Subject — данные о владельце сертификата (содержит много опциональных полей, например в CN (Common Name) обычно указывают домен)
📝 Issuer — данные о подписчике сертификата (например, можно увидеть какой CA (Certificate Authority) подписал этот сертификат)
📝 Public key — публичный ключ сертификата, используется для проверки подписи и шифрования session key (о нем позже)
📝 Valid from — дата создания сертификата
📝 Valid until — срок действия сертификата
📝 Signature — цифровая подпись сертификата, например подписанная CA

Теперь мы представляем что это и для чего это нужно. Остаются вопросы:
❓ Откуда взять сертификаты?
❓ Какие виды сертификатов есть?
❓ С технической точки зрения, как клиент и сервер используют сертификат?

Об этом в следующих статьях. Однако для тех, кто хочет быстрее посмотреть пример Spring Boot сервера c mTLS и скрипт с эмуляцией выдачи CA клиентского и серверного сертификата, можно перейти по ссылке — 🐙Github

#sandbox_spring_web #https

➿ Меню
➿ Подпишись: @developer_sandbox

Ответим на часть вопросов из предыдущей статьи:
❓ Откуда взять сертификаты?
❓ Какие виды сертификатов есть?

Сертификаты можно получить несколькими способами:
— Сгенерировать самостоятельно
— Получить бесплатно, либо купить в специальной организации, имеющей статус Сertificate Authority (CA)

⚠️ Если любой пользователь может генерировать сертификаты, то как браузер либо любой другой клиент, общающийся с HTTPS сервером, понимает что сертификату сервера можно доверять?

Для ответа на этот вопрос у клиента есть изначальный набор сертификатов, и доверенными сертификатами считаются только те, что находятся в этом наборе, который еще называют truststore.
В браузерах, операционных системах и JDK такие наборы сертификатов идут сразу с установкой. А сами сертификаты берутся у доверенных CA компаний (Например DigiCert, Let's Encrypt).
Это значит, что даже если вы сгенерируете свой сертификат, доверять ему смогут только приложения, где у вас есть прямой доступ к их truststore.

Таким образом, можно выделить виды сертификатов по уровню доверия к ним:

📝 Self-signed — самоподписанные сертификаты. Можно сгенерировать самостоятельно, например, через команду openssl. Доверять таким сертификатам сможете только вы, и пользователи, которые специально добавят их в свой truststore.
Технически, корневые сертификаты от CA, установленные по-умолчанию в браузерах и ОС, тоже являются самоподписанными, но им принято доверять.

Если мы получаем сертификат через CA, то в зависимости от количества проверок со стороны CA, есть следующие виды сертификатов:

📝 DV (Domain Validation) — CA организация проверяет, что указанный домен принадлежит действительно человеку, который обратился за получением сертификата. Это самая минимальная проверка, можно провести автоматически и получить сертификат бесплатно, так делает CA организация — Let's Encrypt.

📝 OV (Organization Validation) — CA помимо домена, проверяет еще что ваша организация действительно существует и у нее есть юридический адрес. Такой сертификат будет уже платный.

📝 EV (Extended Validation) — CA помимо предыдущих проверок, проведет ряд дополнительных проверок вашей организации. Такой сертификат будет стоить еще дороже. Больше подходит корпорациям, например, такой сертификат можно посмотреть на сайте apple.

Остаются вопросы, которые мы рассмотрим в следующих статьях:
❓ С технической точки зрения, как клиент и сервер используют сертификат? (Поговорим о TLS-handshake)
❓ Если мы получили сертификат выданный CA, то как клиенты будут ему доверять? Ведь только что выданный сертификат не появится во всех ОС и браузерах как доверенный в их truststore. (Поговорим о certificate chain)

Заранее добавил пример, демонстрирующий работу с цепочками сертификатов — 🐙Github

#sandbox_spring_web #https

➿ Меню
➿ Подпишись: @developer_sandbox

Ответим на вопрос из предыдущей статьи:
❓ Если мы получили сертификат выданный CA, то как клиенты будут ему доверять? Ведь только что выданный сертификат не появится во всех ОС и браузерах как доверенный в их truststore.

Чтобы ответить на этот вопрос, нужно понимать как проверяется сертификат.

Рассмотрим на примере:
Перед запросом сертификата от CA, мы генерируем private key и CSR (Certificate Signing Request). В CSR хранится информация о нашем сайте (например, в поле subject указано поле CN=<домен>), а также public key, связанный с нашим private key.

❓ Что такое private key и public key?
Это понятия из криптографии, а именно из ассиметричного шифрования (например, алгоритм RSA). Здесь нам важно понимать что существует связанная пара ключей:
— Public key можно передавать другим людям, он используется для шифрования и проверки signature (цифровая подпись)
— Private key следует хранить в секрете, он используется для дешифрования и создания signature

После того как CA получил CSR, используя его, а также свой CA сертификат и CA private key, он генерирует нам сертификат (в поле issuer нашего сертификата будет указана информация из subject'a CA сертификата) и мы устанавливаем его на сервер.

❓ Что на этом этапе есть на нашем сервере?
— Сгенерированный нами private key
— Сгенерированный нам от CA сертификат, содержащий наш public key и подпись, сделанную CA private key

❓ А что есть у клиента, который отправит запрос на наш сервер?
— У него есть только CA сертификат, по-умолчанию установленный в truststore его браузера

Теперь клиент отправляет запрос на сервер, и проверка сертификата происходит следующим образом:
1⃣ Получаем сертификат сервера
2⃣ Смотрим значение issuer и ищем в truststore сертификат, у которого такой subject (мы его находим, это CA сертификат)
3⃣ Берем public key из CA сертификата, а signature берем из сертификата сервера
4⃣ Т.к. signature была сделана используя CA private key, то используя CA public key мы проверяем ее и достаем из signature информацию о hash'e сертификата сервера.
5⃣ Смотрим какой алгоритм использовался для генерации hash'a сертификата сервера
6⃣ Откидываем signature и считаем hash для body (body это весь файл сертификата, кроме signature)
7⃣ Если hash из signature и только что рассчитанный hash для body равны, то значит сертификат сервера действительно был подписан CA и ему можно доверять.

Таким образом, имея только корневой CA сертификат, мы можем проверять все выданные этим CA сертификаты.

Это позволяет создавать цепочки сертификатов (certificate chain):
— Например, один крупный CA выдает оптом сертификаты другому CA поменьше, а он уже выдает сертификаты физическим лицам.
— Тогда на сервере будет цепочка сертификатов от разных CA (обязательно в той последовательности, в которой они выдавались)
— Но клиенту все равно достаточно иметь только один корневой сертификат в truststore, который от крупного CA
— Проверка по алгоритму, описанному выше, пройдет по всей цепочке, начиная от корневого сертификата

Этот алгоритм можно полностью самостоятельно провести на практике, я описал скрипт для ручной проверки сертификата (поиск по Manual certificate validation), а также добавил https клиент — 🐙Github

#sandbox_spring_web #https

➿ Меню
➿ Подпишись: @developer_sandbox

🔤🔤🔤🔤

Sandbox 📦
🔤Сравнение JDBC, Spring JDBC, Hibernate, Spring Data JPA
🔤Логирование JDBC запросов
🔤Обзор Spring Data JDBC, MyBatis, JOOQ
🔤Что такое Spring Boot и для чего он используется?

Java Sandbox ☕️
🔤В чем разница между анонимным классом и λ-выражением?
🔤Какие бывают типы λ-выражений?
🔤Как Capturing λ-выражение влияет на GC?
🔤Всегда ли method reference ведет себя как и λ-выражение?
🔤Что такое Happens-before и как воспроизвести эту гарантию?
🔤Для чего применяются volatile и synchronized?

Spring Context Sandbox 🌱
🔤Annotation-based config и как зарегистрировать бин в runtime?
🔤Что делать в случае возникновения циклической зависимости?
🔤Какие бывают способы Dependency Injection?
🔤Как Spring создает бин и какой его жизненный цикл?🫘

Spring Web Sandbox 🌱
🔤Обзор видеоурока "Архитектура кода (Java)"
🔤Что такое SSL сертификаты и для чего они нужны?📜
🔤Откуда взять сертификаты и какие есть виды?📜
🔤Как происходит проверка сертификата?📜

Spring Data JPA Sandbox 🌱
🔤Какие существуют типы связей в JPA?

PostgreSQL Sandbox 🐘
🔤Какие существуют типы связей в реляционных БД?

Apache Kafka Sandbox📖
🔤Что такое Apache Kafka и какие области ее применения?
🔤Основные сущности Apache Kafka. Часть 1
🔤Основные сущности Apache Kafka. Часть 2
🔤Что такое DLT и как это реализовать в Apache Kafka?
🔤Что такое delivery semantics в Apache Kafka?
🔤Консольные инструменты Apache Kafka

Other📐
🔤Более подробное описание канала
🔤Материалы для подготовки в Яндекс, Тинькофф
🔤Обзор книги “От Джуна до Сеньора"
🔤Список литературы
🔤Версии Java
🔤С наступающим 2024 годом🎄
🔤С наступающим 2025 годом🎄

Недавно вышла общедоступная версия Java 21, которая является следующей LTS (Long-term support) версией после Java 17

Смотрел, какие новые фичи добавили в язык и захотел поделиться с вами полезным ресурсом, где я обычно смотрю обновления — javaalmanac

Здесь можно найти информацию по каждой версии Java, начиная с первой и заканчивая той, что на данный момент в разработке (Java 22)

❓ Что тут можно найти?
— Ссылки на спецификации — языка, API, виртуальной машины
— Ссылки на release notes
— Если перейти на конкретную версию, то по каждому уровню (JVM, Language, API), можно увидеть список добавленных фич, многие из которых объясняются с примерами
— В колонке "Compare API to" можно выбрать предыдущие версии, сравнив API до самых мелочей, например, между Java 21 и Java 20 добавился метод isEmoji(int) в Character классе

Заодно решил обновить свои примеры на самые последние версии:
— Перешел на Java 21
— Отрефакторил build.gradle и перешел в нем с Groovy на Kotlin
— Обновил все версии библиотек, а где используется docker — обновил версии imag'ей

Теперь структура примеров еще проще:
🌱 sandbox-spring-context
🌱 sandbox-spring-web
📖 sandbox-kafka
☕️ sandbox-java

#note #sources

➿ Меню
➿ Подпишись: @developer_sandbox

❓ Что такое delivery semantics в Apache Kafka?

Delivery semantics [delivery guarantees, processing guarantees] — это способы доставки сообщений, т.е. как именно будут взаимодействовать между собой Producer, Broker и Consumer для того чтобы доставить сообщение.

Рассмотрим на примере классической схемы. У нас есть:
1⃣ Kafka Cluster с любым количеством Broker’ов
2⃣ Producer — читает данные из БД и отправляет их в виде сообщения Broker’у в demo.topic
3⃣ Consumer — подписан на demo.topic, если сообщение пришло, то читает его и сохраняет данные в БД
Для примера неважно какие используются БД у Consumer’a и Producer’a

Доставка сообщения в нашем случае может состоять из шагов:
Шаг 1. Producer читает данные из БД
Шаг 2. Producer отправляет сообщение Broker’y в demo.topic
Шаг 3. Broker сохраняет сообщение в demo.topic’e
Шаг 4. Broker уведомляет Producer’a, подтверждая что сообщение сохранено [acknowledgment]
Шаг 5. Consumer читает сообщение из demo.topic’a
Шаг 6. Consumer уведомляет Broker’a, что сообщение успешно прочитано [offset commit]
Шаг 7. Consumer сохраняет данные в БД

❓ Что может пойти не так?
На каждом шаге может произойти сбой, например:
❌ Закончилась оперативная память — OutOfMemoryError
❌ Закончилось место на диске
❌ Временный сбой в сети
❌ Случился timeout, например, Шаг 3 — Broker слишком долго сохранял сообщение

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

Delivery semantics для Producer’a:

1⃣ At most once — сообщение будет отправлено максимум 1 раз. Producer отправляет сообщение и не ждет от Broker’a acknowledgment, а если Broker не смог его записать, сообщение больше отправляться не будет, оно утеряно. Принцип ‘fire-and-forget’.

2⃣ At least once — сообщение будет отправлено минимум 1 раз. Producer отправляет сообщение и ждет acknowledgment, а если Broker не отправил acknowledgment, то Producer заново отправит сообщение.
Тут может быть ситуация, если Broker записал сообщение, но вышел из строя на этапе отправки acknowledgment’a, и когда Broker восстановится и Producer переотправит сообщение, то мы по сути создадим дубликат, сохранив в Broker’e дважды одно сообщение.

3⃣ Exactly once — сообщение будет отправлено только 1 раз. Producer отравляет сообщение и ждет acknowledgment, а если Broker не отправил acknowledgment, то Producer заново отправит сообщение, и если Broker упадет на этапе отправки acknowledgment’a и получит дубликат, он это поймет и не будет записывать одно и тоже сообщение дважды. Здесь мы не теряем сообщения и не создаем дубликаты.

Delivery semantics для Consumer’a:

1⃣ At most once — сообщение будет прочитано максимум 1 раз. Consumer читает сообщение из Broker’a и если он не может его обработать, перечитывать его не будет.
У нас Шаг 7, например, Spring приложение Consumer упало с OOM и потом поднялось, но перечитывать сообщение не будет хоть и могло бы записать что-то в БД. Тут мы теряем обработку сообщения.

2⃣ At least once — сообщение будет прочитано минимум 1 раз. Consumer читает сообщение из Broker’a и если он не может его обработать, он заново его перечитает.
У нас Шаг 6 и Шаг 7 меняются местами, однако, например, мы делаем транзакцию в БД, хотим сделать commit offset и падаем с OOM, и когда поднимаемся, то перечитываем сообщение и делаем ту же транзакцию, что может создать дубликат в БД.

3⃣ Exactly once — сообщение будет прочитано только 1 раз. Consumer читает сообщение из Broker’a и если он не может его обработать, он заново его перечитает.
Чтобы не создать дубликат и не потерять обработку сообщения у нас есть 2 варианта:
— Транзакция в БД идемпотентна и если мы повторим ее, то ничего не изменится
— Мы делаем commit offset в рамках транзакции к БД [необязательно хранить offset в Broker’e, можно хранить их в БД], чтобы Шаг 6 и Шаг 7 был одним атомарным шагом. Тогда у нас нет дубликатов и обработку сообщения мы не теряем

Немного рефакторинга — 🐙Github

#sandbox_kafka #spring_boot_kafka

➿ Меню
➿ Подпишись: @developer_sandbox

После продолжительного перерыва, я вернулся с новой статьей. Буду стараться писать одну/две статьи в неделю.

Давайте напишем одинаковое приложение, используя JDBC, Spring JDBC, Hibernate и Spring Data JPA. Посмотрим наглядно, как исторически повышался уровень абстракции при работе с БД в Java мире.

❓ Какое приложение напишем?

CRUD для работы с сущностью Book и ее связями — Author, Comment, Genre

Реализуем API для:
1⃣ Получения всех книг и ее связей
2⃣ Получения книги по id и ее связей
3⃣ Создания книги и ее связей
4⃣ Обновления книги и ее связей
5⃣ Удаления книги и ее комментариев и информации о жанрах

Модель данных опишем таблицами:
1⃣ books — данные о книгах
2⃣ authors — данные об авторах. С books “one-to-one”
3⃣ genres — данные о жанрах
4⃣ comments — данные о комментариях к книгам. С books “one-to-many”
5⃣ books_genres — промежуточная таблица для создания “many-to-many” между books и genres

Начнем в порядке повышения уровня абстракции:

📚 JDBC [Java Database Connectivity] — спецификация синхронного API для работы с реляционными БД из Java приложений. Входит в состав Java SE.

Реализацию API предоставляет JDBC драйвер.
Например, для PostgresSQL есть драйвер postgresql-42.6.0.jar, внутри есть класс PgResultSet, реализующий интерфейс java.sql.ResultSet из JDBC спецификации.

Для отправки SQL запроса, нужно:
1⃣ Получить Connection
2⃣ Создать Statement, передав SQL запрос в виде String
3⃣ Если это параметризованный запрос, то передать параметры через .set методы в Statement’e
4⃣ Выполнить запрос и получить ResultSet
5⃣ Разобрать ResultSet, получив из него данные для создания объектов Book, Author, Comment, Genre
6⃣ Закрыть ResultSet
7⃣ Закрыть Statement
8⃣ Закрыть Connection

Пример доступен на 🐙Github

🌱 Spring JDBC — набор абстракций, упрощяющий написание кода при работе с JDBC. Чтобы как можно меньше шагов пришлось писать самому.

Например, аннотация Transactional для механизма транзакций, класс NamedParameterJdbcOperations для выполнения запросов.

Теперь нам не нужно самостоятельно открывать Connection и закрывать его вместе с Statement и ResultSet. Однако разбирать данные из ResultSet'a все еще нужно вручную.

Пример доступен на 🐙Github

🪞 Hibernate — ORM [Object Relational Mapping] фреймворк. Реализует JPA спецификацию. Переход от реляционной парадигмы в ООП парадигму. Сама реализация для доступа к БД использует тот же JDBC.

Мы начинаем работать с таблицами из БД как с Java объектами. Убирается необходимость самостоятельного разбора ResultSet'ов. Вводится понятие HQL [в спецификации JPA называется JPQL], как универсального языка запросов, для обеспечения независимости от реализации БД.

Однако появляется N+1 проблема, и множество других подводных камней, которые нужно учесть, чтобы ORM фреймворк генерировал оптимальный SQL.

Пример доступен на 🐙Github

🌱 Spring Data JPA — часть umbrella проекта Spring Data, представляет дополнительный уровень абстракции над JPA. По-умолчанию использует Hibernate как JPA реализацию.

Благодаря абстракции Repository, позволяет генерировать запросы на основе имени метода, убирая возможность в некоторых ситуациях писать даже JPQL. Помимо этого имеет и много других возможностей, значительно ускоряя написание кода.

Содержит все те же недостатки что и Hibernate [в случае если используется именно он как реализация JPA].

Пример доступен на 🐙Github

#sandbox_java_database_tools

➿ Меню
➿ Подпишись: @developer_sandbox

Хотел написать в одной статье о типах связей в реляционных БД, и как их реализовать в JPA

Однако в одну статью с примерами кода не поместилось, поэтому разделил на две статьи и создал отдельные репозитории:
🐘 sandbox-postgresql
🌱 sandbox-spring-data-jpa

Если в статье SQL код неправильно отображается, нужно обновить Telegram.

❓ Какие существуют типы связей в реляционных БД?

Рассмотрим на примере нашей любимой доменной модели — Библиотеки
У нас будут две сущности — Книга, Автор
В зависимости от наших требований к системе, мы будем строить нужную связь между сущностями

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

Решение:
Для реализации такой модели данных нам подойдет отношение One to One [читается как “один автор — одна книга”]:

CREATE TABLE authors
(
    id   BIGSERIAL   NOT NULL PRIMARY KEY,
    name VARCHAR(64) NOT NULL
);

CREATE TABLE books
(
    id        BIGSERIAL    NOT NULL PRIMARY KEY,
    title     VARCHAR(128) NOT NULL,
    author_id BIGINT       NOT NULL UNIQUE REFERENCES authors (id)
);

Здесь важно установить UNIQUE constraint, в нашем случае на поле author_id, чтобы разные книги не могли ссылаться на одного автора.

Также вместо author_id, можно сделать book_id в таблице authors, и наше требование тоже выполнится.
Таким образом мы выбираем, кто будет владельцем связи, Book или Author [об этом будет подробнее в статье про Spring Data JPA, но если кратко, тот у кого в таблице foreign key]

Пример доступен на 🐙Github

Требование:
В нашей системе мы хотим чтобы у одной книги был только один автор. Однако, автор может написать сколько угодно книг.

Решение:
В этом случае нам подойдет отношение One to Many [читается как “один автор — множество книг”]
Иногда выделяют отношение Many to One [читается как “множество книг — один автор”], разницы в реализации между ними нету, мы только меняем акцент, когда говорим что с чем связано

CREATE TABLE authors
(
    id   BIGSERIAL   NOT NULL PRIMARY KEY,
    name VARCHAR(64) NOT NULL
);

CREATE TABLE books
(
    id        BIGSERIAL    NOT NULL PRIMARY KEY,
    title     VARCHAR(128) NOT NULL,
    author_id BIGINT       NOT NULL REFERENCES authors (id)
);

Единственная разница в реализации между One to One и One to Many, что теперь у нас нету UNIQUE constraint для поля author_id

Также если мы сделаем book_id в таблице authors вместо author_id в таблице books, то наше требование не выполнится, потому что тогда автор сможет иметь только одну книгу
[Поэтому в JPA у аннотации ManyToOne нету параметра mappedBy, потому что такая сущность точно является владельцем связи, т.е. имеет foreign key на другую сущность]

Пример доступен на 🐙Github

Требование:
В нашей системе мы хотим чтобы у одной книги было сколько угодно авторов. А также, автор может написать сколько угодно книг.

Решение:
Здесь нам подходит Many to Many [читается как “множество авторов — множество книг”]:

CREATE TABLE authors
(
    id   BIGSERIAL   NOT NULL PRIMARY KEY,
    name VARCHAR(64) NOT NULL
);

CREATE TABLE books
(
    id    BIGSERIAL    NOT NULL PRIMARY KEY,
    title VARCHAR(128) NOT NULL
);

CREATE TABLE books_authors
(
    id        BIGSERIAL NOT NULL PRIMARY KEY,
    book_id   BIGINT    NOT NULL REFERENCES books (id),
    author_id BIGINT    NOT NULL REFERENCES authors (id),
    UNIQUE (book_id, author_id)
);

Создается дополнительная таблица books_authors, указывающая нужные связи между сущностями
Не стоит также забывать о добавлении UNIQUE constraint’a на связь book_id и author_id, чтобы связь была уникальной

Пример доступен на 🐙Github

#sandbox_postgresql #relationships

➿ Меню
➿ Подпишись: @developer_sandbox

❓ Как при работе с JDBC настроить логирование SQL запросов?

При использовании ORM на этапе разработки, часто возникает необходимость посмотреть какой именно SQL запрос генерируется для отправки в БД, чтобы вовремя обнаружить ошибки и сравнить ожидаемый запрос с реальным

Желательно, чтобы параметры уже были подставлены для сгенерированного SQL запроса, чтобы можно было его скопировать и используя, например — DBeaver, DataGrip, pgAdmin, отправить и посмотреть на результат, либо более детально его проанализировать

🪞 Hibernate имеет свойства show_sql, format_sql, highlight_sql, позволяющие выводить сгенерированный ORM’ом SQL запрос в форматированном виде

Если добавить логгер — org.hibernate.orm.jdbc.bind: trace, то мы увидим еще и параметры, но в нужное место в запросе нам придется подставлять их самостоятельно

❓ Какие есть еще варианты?

На картинке отображается пример логов при выполнении SQL запроса из примера на 🐙Github. На консоль выводится:

1⃣ Connection URL с дополнительными параметрами
2⃣ SQL запрос с подставленными параметрами
3⃣ ResultSet в виде таблицы, как результат выполнения запроса
4⃣ Json объект, как результат сбора информации из ResultSet’a в сущность

Для получения таких, либо похожих логов, есть несколько инструментов:

1⃣ log4jdbc — proxy для JDBC драйвера. Логирует SQL запрос с подставленными параметрами и время его выполнения. Пример доступен на 🐙Github

2⃣ log4jdbc-remix — форк log4jdbc проекта, добавляющий тот самый вывод ResultSet'a в виде таблицы. Был переименован в log4jdbc-log4j2 как его продолжение, но на данный момент заброшен. Пример доступен на 🐙Github

3⃣ p6spy — более масштабный проект, позволяющий добавлять свои formatter'ы, настраивается более гибко через spy.properties. Пример доступен на 🐙Github

4⃣ datasource-proxy — особых преимуществ над стандартными средствами Hibernate не заметил, но свою задачу выполняет. Пример доступен на 🐙Github

#sandbox_java_database_tools

➿ Меню
➿ Подпишись: @developer_sandbox

❓ Какие существуют типы связей в JPA?

В предыдущей статье, мы поговорили о типах связей в реляционных БД. Давайте рассмотрим их реализации в JPA, на примере нашей доменной модели — Библиотеки, где у нас есть две сущности — Author и Book

Начнем с One to One, который можно реализовать двумя способами:
1⃣ Через аннотацию MapsId [этот вариант мы рассмотрим в отдельной статье]
2⃣ Через аннотацию OneToOne:

    // Book.class
    @OneToOne
    // Annotation @JoinColumn(name = "author_id", nullable = false, unique = true) can be skipped,
    // because of default name mapping
    private Author author;

❓ А что в классе Author?
Представим, что мы вновь работаем только с SQL. Тогда, зная id сущности Author, мы можем получить как самого автора, так и его книгу. [автора по id, а книгу по author_id].

Теперь, возвращаемся к JPA. Если у нас нету ссылки на класс Book в классе Author, то по-умолчанию, самого автора получить мы можем, а вот его книгу — нет. Чтобы исправить это, нам нужно указать связь и в классе Author:

     // Author.class
     /*
     * One Author to One Book
     * Bidirectional relationship
     * Owner of the relationship is Book [because books table contains foreign key to authors table],
     * linked by 'author' field in Book class
     */
    @OneToOne(mappedBy = "author")
    private Book book;

Таким образом, в JPA выделяют два типа связей:
1⃣ Unidirectional — когда мы взаимодействуем только с owning side [тот, кто имеет foreign key, в нашем примере — Book.class]
2⃣ Bidirectional — когда нам необходимо через unowned side [тот, на кого ссылаются через foreign key, в нашем примере — Author.class], получить доступ к owning side [Book.class]. Для этого существует параметр mappedBy, в котором указывается поле из owning side [Book.class], которое ссылается через foreign key на unowned side [Author.class].

При использовании Bidirectional связи, появляются дополнительные проблемы, которые необходимо учитывать, например:
❌ В методах equals, hashCode, toString, а также при сериализации можно получить java.lang.StackOverflowError
❌ Если мы меняем только unowned side, без изменения owning side, то автоматически такие изменения не будут синхронизорованы с БД
❌ Для write операций необходимо поддерживать Bidirectional setter'ы, чтобы данные оставались консистентными в БД

Unidirectional пример доступен на 🐙Github
Bidirectional пример доступен на 🐙Github

One to Many и Many to One:

    // Book.class
    @ManyToOne
    // Annotation @JoinColumn(name = "author_id", nullable = false) can be skipped,
    // because of default name mapping
    private Author author;
    
    // Author.class
    /*
     * One Author to Many Books
     * Bidirectional relationship
     * Owner of the relationship is Book [because books table contains foreign key to authors table],
     * linked by 'author' field in Book class
     */
    @OneToMany(mappedBy = "author")
    private Set<Book> books;

Hibernate не советует использовать аннотацию OneToMany без ManyToOne, о чем упоминается в документации

Unidirectional пример доступен на 🐙Github
Bidirectional пример доступен на 🐙Github

Many to Many:

    // Book.class
    @ManyToMany
    @JoinTable(
            name = "books_authors",
            joinColumns = @JoinColumn(name = "book_id", nullable = false),
            inverseJoinColumns = @JoinColumn(name = "author_id", nullable = false)
    )
    private Set<Author> authors;

    // Author.class
    /*
     *
     * Many Authors to Many Books
     * Bidirectional relationship
     * Owner of the relationship is Book,
     * linked by 'authors' field in Book class. If required, Author can be owner side
     */
    @ManyToMany(mappedBy = "authors")
    private Set<Book> books;

Если возникает необходимость добавить дополнительные колонки в таблицу со связями и использовать их, то придется создавать дополнительную Entity. Об этом случае хорошо написано в документации

Unidirectional пример доступен на 🐙Github
Bidirectional пример доступен на 🐙Github

#sandbox_spring_data_jpa #relationships

➿ Меню
➿ Подпишись: @developer_sandbox

Наступает 2024 год ♥️

Хочу пожелать всем успехов в Новом Году! 🎄🎁

Тем, кто ищет работу - найти ее и стать частью хорошей команды 🎁
Тем, кто уже работает - профессиональных достижений и комфортных сроков 🎁
Какой бы уровень знаний ни был, мы продолжаем учиться и получать новый опыт, а обмениваясь им, мы экономим время и силы друг друга ✅

Благодарю вас за то, что читаете этот канал, ставите реакции и пишете комментарии! 🐱
И поздравляю Вас с наступающим 2024 годом!❄️

———
Небольшая статистика:
Канал создан 14.06.2022
Первый пост я опубликовал 15.07.2023, вышло, что от идеи до начала реализации прошел год и 1 месяц
На сегодняшний день '31.12.2023', написано 28 постов и 41 пример на 🐙Github, они доступны в обновляющемся Меню

———
Обновление:
В IDEA есть Run Configurations, благодаря которым можно по одному клику настроить, что конкретно будет запускаться, и их можно сохранить в файл
Т.е. когда кто-то через IDEA откроет проект, они будут у него доступны

Я добавил их в каждый репозиторий:
📦 sandbox
☕️ sandbox-java
🌱 sandbox-spring-context
🌱 sandbox-web
🐘 sandbox-postgresql
🌱 sandbox-spring-data-jpa
📖 sandbox-kafka

Особенно это удобно для 📖sandbox-kafka, в котором, по одному клику можно запустить кластер с одним брокером, либо с двумя, либо добавить мониторинг, и еще, в дополнении к confluentinc image, добавились и другие — bitnami и wurstmeister