Как Spring Data Jdbc соединяет таблицы

В этом посте мы рассмотрим, как Spring Data Jdbc строит sql-запросы для извлечения связных сущностей.
Пост рассчитан на начинающих программистов и не содержит каких-то супер хитрых вещей.

Приглашаю всех на demo day онлайн-курса «Java Developer. Professional». В рамках мероприятия я подробно расскажу о программе курса, а также отвечу на интересующие вас вопросы.

Очень часть решения типа Hibernate используют, т.к. это очень удобно для работы с вложенными объектами.
Например, есть класс RecordPackage одним из полей этого класса является коллекция дочерних (или вложенных) объектов: records.
Если использовать Jdbc, то придется писать довольно много рутинного кода. Это мало кому нравится, отчасти поэтому и используют Hiberhate.
C Hibernate можно вызовом одного метода сразу получить RecordPackage со всеми его дочерними объектами records.
Хочется с одной стороны пользоваться одним методом для получения всего объекта, а с другой – не хочется связываться с монстром Hibernate.
Spring Data Jdbc позволяет получить лучшее из этих двум миров (или по крайней мере что-то приемлемое).
Рассмотрим два случая:

• отношение one-to-many
• отношение one-to-one

Именно эти связи в практике встречаются чаще всего.
Полный код примеров можно будет найти на GitHub, здесь я приведу только самый минимум.
Прежде всего, стоит отметить, что Spring Data Jdbc – это не волшебный инструмент, решающий любые проблемы. У него, конечно, есть свои недостатки и ограничения.
Однако для ряда типовых задач это вполне подходящее решение.

Отношение One-to-many

В качестве реального примера можно рассмотреть: заголовок пакета неких данных и строки данных, входящие в этот пакет. Например, файл — это пакет, а строки файла — это строки данных, входящие в этот пакет.
Структура таблиц такая:

create table record_package (     record_package_id bigserial    not null         constraint record_package_pk primary key,     name              varchar(256) not null );  create table record (     record_id         bigserial    not null         constraint record_pk primary key,     record_package_id bigint       not null,     data              varchar(256) not null );  alter table record     add foreign key (record_package_id) references record_package; 

две таблицы: record_package (заголовок некого пакета) и record (записи, входящие в пакет).
Как эта связь отображается в java-коде:

@Table("record_package") public class RecordPackage {     @Id     private final Long recordPackageId;     private final String name;      @MappedCollection(idColumn = "record_package_id")     private final Set<Record> records; …. } 

Тут нас интересует определение связи one-to-many. Это кодируется с помощью аннотации @MappedCollection.
У этой аннотации два параметра:
idColumn – поле, по которому осуществляется связь
keyColumn – поле, по которому упорядочиваются записи в дочерней таблице.

Про это упорядочивание стоит сказать отдельно. В этом примере нам не важно, в каком порядке дочерние записи будут вставлены в таблицу record, но в каком-то случае это может быть принципиально. Для такого упорядочивания в таблице record будет поле вроде record_no, вот именно это поле и надо будет прописать в keyColumn аннотации MappedCollection. При выполнении insert Spring Data Jdbc будет генерировать значения этого поля. В дополнение к аннотации, Set надо будет заменить на List, что вполне логично и понятно. Явно заданная последовательность дочерних строк будет учтена и при формировании select, но к этому мы еще вернемся.

Итак, мы определили связи и готовы попробовать это в деле.
Создаем связанные сущности и получаем их из базы:

  var record1 = new Record("r1");   var record2 = new Record("r2");   var record3 = new Record("r3");     var recordPackage = new RecordPackage( "package", Set.of(record1, record2, record3));    var recordPackageSaved = repository.save(recordPackage);     var recordPackageLoaded = repository.findById(recordPackageSaved.getRecordPackageId()); 

Обратите внимание, что нам достаточно вызвать один метод repository.findById, чтобы получить экземпляр RecordPackage с заполненной коллекцией records.

Конечно, нас интересует, какой именно sql-запрос был выполнен для получения вложенной коллекции records.
По сравнению в Hibernate, Spring Data Jdbc хорош своей простотой. Его достаточно легко можно продебажить, чтобы выявить основные моменты.
После небольшого расследования в пакете org.springframework.data.jdbc.core.convert находим класс DefaultDataAccessStrategy. Этот класс отвечает за генерацию SQL-запросов на основе информации о классе. Сейчас в этом классе нас интересует метод

Iterable<Object> findAllByPath

А еще точнее строка:

String findAllByProperty = sql(actualType)      .getFindAllByProperty(identifier, path.getQualifierColumn(), path.isOrdered()); 

Тут из внутреннего кеша извлекается нужный SQL-запрос.
В нашем случае он выглядит так:

SELECT "record"."data" AS "data", "record"."record_id" AS "record_id", "record"."record_package_id" AS "record_package_id"  FROM "record"  WHERE "record"."record_package_id" = :record_package_id 

Все понятно и предсказуемо.
А как бы он выглядел, если бы мы использовали упорядоченность записей в дочерней таблице? Очевидно, потребовался бы order by.
Перенесемся в класс BasicRelationalPersistentProperty пакета org.springframework.data.relational.core.mapping. В этом классе есть метод, который определяет, надо ли добавить к запросу order by или нет.

	 public boolean isOrdered() {   return isListLike(); } 

и

private boolean isListLike() {   return isCollectionLike() && !Set.class.isAssignableFrom(this.getType()); } 

isCollectionLike проверяет, что у нас действительно «коллекция» (включая массив).
А из условия !Set.class.isAssignableFrom(this.getType()); становится понятно, что Set у нас используется не случайно, а чтобы исключить ненужную сортировку. А когда-то мы намеренно будем использовать List, чтобы сортировку включить.

Думаю, в one-to-many более или менее понятно, давайте перейдем к следующему случаю.

Отношение One-to-one

Допустим, у нас такая структура.

create table info_main (     info_main_id bigserial    not null         constraint info_pk primary key,     main_data    varchar(256) not null );  create table info_additional (     info_additional_id bigserial    not null         constraint additional_pk primary key,     info_main_id       bigint       not null,     additional_data    varchar(256) not null );  alter table info_additional     add foreign key (info_main_id) references info_main; 

Есть таблица с основной информацией по некому объекту (info_main) и есть дополнительная информация (info_additional).
Как это можно представить в коде:

@Table("info_main") public class InfoMain {     @Id     private final Long infoMainId;     private final String mainData;      @MappedCollection(idColumn = "info_main_id")     private final InfoAdditional infoAdditional; … } 

На первый взгляд похоже на первый случай one-to-many, но есть отличие. В этот раз дочерний объект действительно объект, а не коллекция как в предыдущем случае.

Код для тестирования выглядит так:

  var infoAdditional = new InfoAdditional("InfoAdditional");    var infoMain = new InfoMain("mainData", infoAdditional);    var infoMainSaved = repository.save(infoMain);   var infoMainLoaded = repository.findById(infoMainSaved.getInfoMainId()); 

Посмотрим, какое sql-выражение сформируется в этот раз. Для этого раскопаем метод findById до места:
Пакет org.springframework.data.jdbc.core.convert класс DefaultDataAccessStrategy. Этот класс нам уже знаком, сейчас нас интересует метод.

public <T> T findById(Object id, Class<T> domainType) 

Видим, что из кеша извлекается такой запрос:

SELECT "info_main"."main_data" AS "main_data", "info_main"."info_main_id" AS "info_main_id", "infoAdditional"."info_main_id" AS "infoadditional_info_main_id", "infoAdditional"."additional_data" AS "infoadditional_additional_data", "infoAdditional"."info_additional_id" AS "infoadditional_info_additional_id"  FROM "info_main"  LEFT OUTER JOIN "info_additional" "infoAdditional"  ON "infoAdditional"."info_main_id" = "info_main"."info_main_id"  WHERE "info_main"."info_main_id" = :id 

Сейчас left outer join нас устраивает, но что, если нет. Как получить inner join?
Функционал создания join-ов находится в пакете org.springframework.data.jdbc.core.convert, класс SqlGenerator, метод:

private SelectBuilder.SelectWhere selectBuilder(Collection<SqlIdentifier> keyColumns)

Нас интересует этот фрагмент:

		 for (Join join : joinTables) {   baseSelect = baseSelect.leftOuterJoin(join.joinTable).on(join.joinColumn).equals(join.parentId); } 

Если надо соединять таблицы, то есть вариант только с left outer join.
Похоже, inner join пока сделать не получается.

Заключение

Мы рассмотрели два наиболее типовых случая как можно соединять таблицы в Spring Data Jdbc.
В принципе, функционал, который сейчас есть, вполне пригоден для решения практических задач, хотя и есть некритичные ограничения.

Полный текст примера можно посмотреть тут.
А тут видео-версия этого поста.