Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.

Я уже выпускал статью по мотивам вопросов в рамках Spring Айо Академии. Так вот, когда мы разгребали отзывы с первого потока, мы также получили вопрос (это не прямая цитата, я лишь передаю посыл в том виде, как я его понял):

А что насчет натуральных ключей в БД? Если, допустим, у меня есть поле, по которому я могу явно идентифицировать запись, стоит ли его использовать как Primary Key?

И я за время дизайна enterprise систем, и за время дизайна Axelix пришёл к выводу: Просто не используйте натуральные ключи вообще никогда. Когда у вас появляется такое желание - выйдите на свежий воздух, пройдитесь, прогуляйтесь, и вас отпустит.

Привет, друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

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

Я обещался на все эти вопросы ответить в рамках статьи. На самом деле, одной статьи у меня не вышло, скорее всего, будет серия статей. Надеюсь, будет интересно :)

Всем привет!

Вероятно, часть людей уже меня знает, но всё же представлюсь. Меня зовут Михаил Поливаха, я являюсь техническим лидером проекта Axelix.

Я уже какое-то время назад выпускал статью, которая поясняла, что такое Copyright, что такое лицензия в общем её смысле, какие типы лицензий бывают и т.д. Рассматривайте данную статью как некое продолжение этой прошлой статьи.

Сегодня я хочу осветить такой момент, как CLA и почему в том или ином виде он есть у любого крупного Open Source-а. Мы также рассмотрим, как AI влияет на CLA и на принятие контрибьюшенов со стороны. Есть ещё DCO. Его, например, уже давно использует Linux, и Spring Framework в своё время перешёл на него с CLA. Но DCO, я думаю, стоит обсудить отдельно. Если интересно будет - пишите, я потрачу время, расскажу.

В общем, без долгих прелюдий, начнём.

Всем привет, меня зовут Михаил Поливаха, я являюсь техническим лидером проекта Axelix.

В Axelix со временем добавляется всё больше и больше сторонних контрибьютеров, которых мы очень приветствуем. И всё больше и больше я сталкиваюсь с некоторым непониманием некоторых строгих гайдлайнов, которые установлены на проекте. Именно сегодня, речь пойдёт про размер PR-а.

У нас есть собственный GitHub Action, который блокирует PR в том случае, если суммарное количество измененных строк кода превышает 500.

Привет, Друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

В рамках программы Hibernate в Spring АйО Academy мы краем обсудили тему, касаемую того, что @OneToOne отличается от других отношений. В частности, Hibernate может спокойно грузить его Eagerly, даже если вы явно поставите FetchType.LAZY. У парней был закономерный вопрос - почему?

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

Иными словами, я в статье постараюсь детально пояснить:

Что на самом деле такое FetchType.LAZY?

Почему @OneToOne не всегда возможно сделать Lazy именно в Java?

Почему при этом @ManyToOne можно сделать Lazy всегда (предполагая не final класс сущности)?

Разберём по шагам.

Привет, Друзья!

Хотел написать короткий пост по мотивам одного казалось бы простого ПР-а, который мы недавно получили в рамках Axelix: Open Core продукта для решения основных известных болей при разработке Spring Boot приложений (кстати, give us a star!).

В общем, контрибьютор пришёл к нам и исправил с виду совершенно безобидную проблему, которую мы упустили. Но на деле, эта проблема со временем могла привести к другим багам, которые дебажить было бы крайне тяжело. И я посчитал, что это стоит небольшой статьи, потому что сам помню проблемы в Spring Data, которые возникали из-за подобных просчётов.

Я не буду погружать вас в детали того, что мы делали, просто покажу на абстрактном примере.

Давайте с места в карьер. Посмотрите на этот код:

Привет, Хабр!

В Axelix мы в последнее время начали получать contribution-ы извне. И как по приватным обсуждениям, так и по GitHub я могу сделать вывод, что у очень многих людей есть довольно серьёзное непонимание того, что означает та или иная лицензия, что вообще такое “Open Source” и даже что такое Copyright.

Мне кажется, что я пару вещей в этой теме немного понимаю, и я чувствую некоторую ответственность этим знанием поделиться. Поэтому я решил написать небольшую статью, которая объясняет базовые концепции в Software, начиная с Copyright и Licensing.

Позже я, возможно, ещё напишу про CLA, Open Core и про то, как AI Agents и AI в целом вписываются в эту картину. Так что, если вам интересно, дайте знать :)

Прежде чем мы начнём: я не юрист, и я не советую вам выбирать ту или иную лицензию, или подход. Я всего лишь Software Engineer, который писал много кода под разными лицензиями, в том числе проприетарными и Open Source.

Давайте я попробую объяснить, как вообще вся юридическая часть вокруг софта устроена, шаг за шагом.

Привет, Хабр!

Меня зовут Михаил Поливаха. Я думаю, что в Хабе Spring АйО меня уже относительно знают. В рамках Spring АйО мы довольно часто занимаемся подбором технического материала и его ревью. Сам же я довольно регулярно выступаю на конференциях, контрибьючу в Open Source и т.д.

Также, часто наши материалы крутятся вокруг Java разработки и конечно же Spring-а. И данной пост, хоть и будет с одной стороны сильно связан с Java и Spring Framework, но, тем не менее, не похож на остальные.

На днях произошло довольно знаковое событие. Мы с небольшой командой примерно год писали инструмент, который призван существенно упростить весь процесс отладки, тестирования и мониторинга Spring Boot приложений в production. И вот этот проект наконец-то получил первый Milestone Релиз.

Проект называется Axelix.

Это не совсем привычная для меня статья, но я давно хотел поделиться одним своим наблюдением. В ней не будет никаких вещей, связанных непосредственно с разработкой на Java или Kotlin, не будет кода. Я просто решил поделиться опытом. Я надеюсь, читать эту статью Вы будете вечером, в спокойный, выходной день.

Ну что же, поехали.

Я предполагаю, что Spring АйО читают в основном Java или Kotlin разработчики. В том или ином виде, Java / Kotlin разработчики часто пишут какие-то Enterprise решения. Одной из отличительных особенностей enterprise является сложная доменная область. Если Вы хотя бы какое-то время писали Enterprise бекенд, то я думаю, для Вас это не новость.

Данная статья является переводом анонса Гевина Кингa о релизе первого milestone JPA 4 спецификации и общего вектора развития JPA.

Полноценная 4-ая версия JPA спецификации должна выйти чуть-чуть позже в этом году. Тем не менее, то, что сейчас в Milestone это основа, которая, возможно, с небольшими доработками, но уже пойдёт в релиз в этом году.

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

P.S: У нас в рамках Spring АйО Академии как раз есть программа посвящённая Hibernate. В ней мы тоже затронем новую версию спецификации, в частности и работу со StatelessSession и EntityAgent на практике. Я думаю, что из всего апдейта, именно стандартизация работы без Persistence Context будет самым важным для прикладных разработчиков. Остальное тоже важно, но не так как работа с EntityAgent.

Приятного чтения!

Я уже давно хотел на этот счет написать статью. Она короткая, но имхо она нужна.

Давайте с места в карьер: merge в Hibernate это не универсальный save, и чаще всего он Вам не нужен.

На самом деле, если абстрагироваться, то это специализированная операция для случая, когда у вас есть detached-сущность, и вы хотите перенести ее состояние в текущий Persistence Context.

Проблема в том, что на практике merge очень часто используют для апдейта любой сущности (Spring Data JPA иногда так делает) и как следствие получают лишние SQL-запросы.

Ниже разберем на мой взгляд главное - почему именно так происходит, где merge действительно нужен, а где он превращается в антипаттерн (P.S да почти везде).

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д.

Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью.

В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах.

Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC.

Данная публикация является переводом статьи Jeff-a Atwood-а почти 20-ти летней давности. Jeff Atwood, один из фаундеров StackOverFlow, написал эту статью как некоторое резюме того, как человечество боролось с проблемой O/R Impedance Mismatch.

Я частично принимаю участие в написании разных ORM решений, например, Spring Data JDBC / R2DBC, и скоро мы вместе с Amplicode проведем online событие (оно бесплатное) по Spring Data JDBC. Будем обсуждать Spring Data JDBC, что в ней хорошо а что в ней плохо. Какие trade-off-ы она имеет.

Я решил выпустить данный перевод с целью того, чтобы напомнить людям - silver bullet-а Spring Data JDBC не придумала. Она лишь заняла конкретную позицию по ряду вопросов, из чего следуют определённые ограничения и преимущества. Их мы и обсудим.

Это довольно короткая статья, целью которой является пояснение того, что вообще такое "модуляризация" Spring Boot, почему она появилась и откуда, собственно, ноги растут.

Для многих Spring Boot это просто автоконфигурация. Само собой Spring Boot гораздо шире и включает в себя в том числе ещё и

Spring Boot Actuator

Spring Boot DevTools

Spring Boot Tools и т.д.

Скоро в Java (предположительно, что уже непосредственно в JDK 26) попадут изменения, которые сначала будут выдавать warning-и при попытках изменения final полей, а потом и вовсе запретят изменения final полей в общем случае (это уже, предположительно, в следующих релизах).

Я периодически катаюсь на различные европейские конференции, и уже давольно давно на них от ключевых архитекторов Java, таких как Brian Goetz, Stuart Marks (довольно известный на конференциях по прозвищу "Dr. Deprecator"), Mark Reinhold и др. превалировал сентимент, который впоследствии переродился в идеалогию под названием "Integrity By Default". В рамках Spring Айо мы уже как-то вскольз о ней упоминали, но не формализовывали. Я предлагаю сначала начать с неё, и потом уже раскручивать непосредственно всю эпопею с final в Java.

Большинство enterprise-приложений работают с БД в том или ином виде. Чаще всего в качестве БД выступает реляционная DBMS, например, PostgreSQL или Oracle. Относительно часто для доступа к данным используют Hibernate. Ранее он предлагал только одну спецификацию — JPA (Java Persistence API), она же Jakarta. Но теперь Hibernate реализует ещё и Jakarta Data.

Jakarta Data — это новая спецификация под зонтиком проекта Jakarta EE (как и JPA), которая упрощает интеграцию данных в корпоративных Java-приложениях. Обе эти спецификации разрабатывает Eclipse Foundation, и в частности Gavin King, создатель Hibernate.

Большинство разработчиков привыкли работать с Hibernate именно через Spring Data JPA. Изначально, когда только обсуждали спецификацию Jakarta Data, Spring Data (не обязательно JPA) была одним из тех проектов, который, в перспективе, мог бы реализовать спецификацию Jakarta Data. Но этого не произошло, и, несмотря на то, что изначально команда Spring Data была вовлечена в процесс создания спецификации, они отказались от идеи реализовывать Jakarta Data, и та стала развиваться самостоятельно. Сегодня Jakarta Data применяют в Hibernate, Open Liberty и ряде более мелких решений. Как же так вышло?

Меня зовут Михаил Поливаха, я практикующий инженер и активный коммитер Spring Data. В этой статье я расскажу об особенностях Jakarta Data, как она появилась и чем отличается от конкурентных решений. Я также расскажу, что помешало команде Spring Data реализовать Jakarta Data, и что же нас ждёт дальше.

В Spring Framework 7 появился новый API — BeanRegistry, который упрощает и расширяет возможности по динамической регистрации бинов. Это особенно актуально, когда невозможно заранее предсказать, сколько компонентов потребуется, как в случае со Spring Data. В новой статье от эксперта сообщества Spring АйО, Михаила Поливахи, вы узнаете:

– Как Spring Data справлялась с динамической регистрацией раньше;

– Какие подходы регистрации существовали до BeanRegistrar, как они работали;

– Как новый API связан со Spring AOT.