JPA отлично справляется с полными графами. А что насчёт частичных?

JPA не предоставляет first-class модель для частичных вложенных графов как концепта. Для этого нужны JDBC (ручная сборка), jOOQ (MULTISET) или Blaze Persistence (Entity Views).

Большинство обсуждений вокруг persistence начинается не с той проблемы. Мы сравниваем фреймворки, SQL-инструменты, ORM… Но реальная проблема проще и фундаментальнее:

Реляционный JOIN результат имеет плоскую форму по умолчанию. Приложениям нужны вложенные объектные графы или специализированные формы данных.

Реляционная реальность

Рассмотрим простую модель: Owner → Pet → Visit

В реляционной базе — три таблицы с foreign key связями. После JOIN:

Дублирование строк, картезианский взрыв, несоответствие структуры. Это не баг фреймворка. Это фундаментальное несоответствие между реляционной и объектной моделями.

EntityGraph: управление загрузкой, не формой данных

@EntityGraph(attributePaths = { "pets", "pets.visits" })
Owner findById(String id);

Один запрос, нет N+1, загружается полный граф. Но здесь важно понять ограничение:

• EntityGraph управляет загрузкой, identity graph - какие связи подгрузить и когда.

• Projection управляет shape of result, то есть какую форму должны принять данные.

Это разные задачи. EntityGraph отвечает на вопрос «как загрузить полный граф?». Но не на вопрос «что если нужна другая форма?»

Например:

record OwnerListView(
    String id,
    String name,
    List<String> pets  // только имена, не сущности
)

Здесь не нужны Visit-сущности и полная модель Pet. EntityGraph здесь заканчивается.

Реальная проблема: кто строит граф?

Кто отвечает за построение вложенного объектного графа?

Это ось архитектурного выбора:

• JDBC → граф строит приложение

• jOOQ → граф строит SQL-абстракция

• Blaze → граф строит ORM

Разные инструменты решают одну и ту же проблему на разных архитектурных уровнях.

Подход 1. JDBC: граф строит приложение

SQL возвращает плоские строки. Граф собирается вручную за один проход - паттерн accumulator:

static List<OwnerProjection> extractWithGraph(ResultSet rs) throws SQLException {
    Map<String, OwnerProjection> owners = new LinkedHashMap<>();

    while (rs.next()) {
        String ownerId = rs.getString("owner_id");

        OwnerProjection owner = owners.computeIfAbsent(
            ownerId, id -> OwnerProjection.of(id, rs.getString("owner_name"))
        );

        String petId = rs.getString("pet_id");
        if (petId != null) {
            PetProjection pet = owner.getOrCreatePet(petId, rs.getString("pet_name"));

            String visitId = rs.getString("visit_id");
            if (visitId != null) {
                pet.getOrCreateVisit(visitId, rs.getDate("visit_date").toLocalDate());
            }
        }
    }
    return List.copyOf(owners.values());
}

getOrCreatePet и getOrCreateVisit - computeIfAbsent внутри каждого аккумулятора:

class OwnerProjection {
    private final Map<String, PetProjection> pets = new LinkedHashMap<>();

    PetProjection getOrCreatePet(String id, String name) {
        return pets.computeIfAbsent(id, k -> PetProjection.of(id, name, this.id));
    }
}

class PetProjection {
    private final Map<String, VisitProjection> visits = new LinkedHashMap<>();

    VisitProjection getOrCreateVisit(String id, LocalDate date) {
        return visits.computeIfAbsent(id, k -> VisitProjection.of(id, date, this.id));
    }
}

OwnerProjection, PetProjection, VisitProjection - мутабельные аккумуляторы, скрытые за package-private. Наружу выходят только иммутабельные record-типы через ViewMapper.

Результат одного прохода:

• полный контроль над SQL

• один запрос, нет N+1

• нет внешних зависимостей — промежуточные классы на каждый уровень — ручная дедупликация через LinkedHashMap

Рабочий пример:

github.com/java-backend-architecture/persistence-graph-extraction-jdbc

Подход 2. jOOQ MULTISET: граф строит SQL-абстракция

jOOQ переносит сборку графа в SQL-слой. Запрос сразу возвращает вложенную структуру:

dsl.select(
    OWNERS.ID,
    OWNERS.NAME,
    multiset(
        select(
            PETS.ID, PETS.NAME, PETS.OWNER_ID,
            multiset(
                select(VISITS.ID, VISITS.DATE, VISITS.PET_ID)
                    .from(VISITS)
                    .where(VISITS.PET_ID.eq(PETS.ID))
            ).convertFrom(r -> r.map(Records.mapping(VisitView::new)))
        )
        .from(PETS)
        .where(PETS.OWNER_ID.eq(OWNERS.ID))
    ).convertFrom(r -> r.map(Records.mapping(PetView::new)))
)
.from(OWNERS)
.fetch(Records.mapping(OwnerView::new));

Никаких промежуточных проекций, никакой ручной дедупликации. Records.mapping собирает record-типы напрямую.

Для плоского списка ещё лаконичнее:

dsl.select(
    OWNERS.ID,
    OWNERS.NAME,
    multiset(
        select(PETS.NAME)
            .from(PETS)
            .where(PETS.OWNER_ID.eq(OWNERS.ID))
    ).convertFrom(r -> r.map(rec -> rec.get(PETS.NAME)))
)
.from(OWNERS)
.fetch(Records.mapping(OwnerListView::new));

• нет ручной сборки графа

• типобезопасность на уровне таблиц и колонок

• минимум вспомогательного кода, требует кодогенерации, порядок полей в SELECT должен совпадать с порядком параметров конструктора, проверяется только в рантайме, MULTISET в production требует PostgreSQL или другой СУБД с полной поддержкой, H2 используется только в тестах для упрощения локального запуска

Рабочий пример:

github.com/java-backend-architecture/persistence-graph-extraction-jooq

Подход 3. JPA + Blaze Persistence: граф строит ORM

Blaze вводит декларативную модель через Entity Views:

@EntityView(OwnerEntity.class)
interface OwnerEntityView {
    @IdMapping String getId();
    String getName();
    List<? extends PetEntityView> getPets();
}

@EntityView(PetEntity.class)
interface PetEntityView {
    @IdMapping String getId();
    String getName();
    @Mapping("owner.id") String getOwnerId();
    List<? extends VisitEntityView> getVisits();
}

Форма данных описывается декларативно. Blaze генерирует оптимизированные запросы автоматически. Но это не магия без настройки. Каждая вьюха регистрируется явно:

@Bean
EntityViewManager entityViewManager(CriteriaBuilderFactory cbf) {
    EntityViewConfiguration config = EntityViews.createDefaultConfiguration();
    config.addEntityView(OwnerEntityView.class);
    config.addEntityView(PetEntityView.class);
    config.addEntityView(VisitEntityView.class);
    config.addEntityView(OwnerListEntityView.class);
    return config.createEntityViewManager(cbf);
}

Маппинг в application read-модель по прежнему выполняет ViewMapper:

var setting = EntityViewSetting.create(OwnerEntityView.class);
var cb = cbf.create(em, OwnerEntity.class).where("id").eq(id);

return evm.applySetting(setting, cb)
    .getResultList()
    .stream()
    .findFirst()
    .map(ViewMapper::toView);

По умолчанию Blaze генерирует один оптимизированный запрос. При нескольких независимых коллекциях в одном EntityView может выполнить отдельный запрос для каждой. Для полной типобезопасности предикатов: where(OwnerEntity_.id).eq(id)

• декларативные проекции

• оптимизированные запросы генерируются автоматически

• нет ручной дедупликации, генерируемый SQL скрыт, сложнее предсказать форму запроса и reasoning о производительности, при сложных графах возможен query explosion, нужна явная верификация, на production требует BlazeConfig и регистрации каждой вьюхи, дополнительная зависимость

Рабочий пример:

github.com/java‑backend‑architecture/persistence‑graph‑extraction‑jpa

Сравнение

Когда что выбирать

• JDBC - полный контроль над SQL, нет желания тащить зависимости, нестандартные формы данных. Цена - промежуточные классы и ручная дедупликация.

• jOOQ - типобезопасность на уровне SQL и готовность к кодогенерации. Лучший баланс между контролем и лаконичностью для сложных проекций.

• JPA + Blaze - уже используете JPA, нужны декларативные проекции с минимумом ручного маппинга. Принимайте в расчёт: SQL скрыт, поведение на production нужно верифицировать отдельно.

Ключевая мысль

Persistence это не про то, как загрузить данные.

Это про то, кто и где формирует их структуру.

• JDBC → приложение контролирует каждый шаг

• jOOQ → SQL-слой берёт сборку на себя

• Blaze → ORM декларирует форму и генерирует запрос

Выбор инструмента — это выбор того, где живёт ответственность за сборку графа. И это решение влияет на архитектуру всего persistence-слоя.

Загружать данные легко. Правильно формировать их структуру это настоящая инженерная задача.