Не работает fetchplan

Есть главная сущность Order, она связана с некоторыми другими сущностями.
В целях оптимизации и повышения производительности нужно было не полностью подкачивать эту сущность, а точнее подкачивать все, кроме коллекции document_packages. Я написал fetchplan и попытался его применить, но все равно подкачивается document_packages, хотя по хорошему, там должен быть null.
Фетч план:

<fetchPlans xmlns="http://jmix.io/schema/core/fetch-plans">
    <fetchPlan class="ru.mtsbank.lkpbackoffice.entity.Order"
               name="moos"
               extends="_local"
    >
        <property name="partner" fetchPlan="_base"/>
        <property name="events" fetchPlan="_base"/>
    </fetchPlan>
</fetchPlans>

Код, в котором проверяю, подкачивается ли document_packages:

FetchPlan fetchPlan = fetchPlanRepository.getFetchPlan(Order.class, "moos");
        var list = dataManager
                .load(Order.class)
                .query("select o from Order_ o")
                .fetchPlan(fetchPlan)
                .list();
        log.info(list.toString());

Верия jmix 1.2.4

P.S. Попробовал использовать даже встроенный фетч план _local, который должен подкачивать только примитивы, но даже он не сработал и подкачиваются все ссылочные атрибуты

Добрый день,

Возможно при вызове list.toString срабатывает ленивая загрузка? Можно в логах посмотреть SQL-запрос, проверить какие таблицы и колонки загружаются.

Я тоже так думал, поэтому toString заранее подделал:

    @Override
    public String toString() {
        String docstr;
        if (documentPackages == null) {
            docstr = "null";
        } else {
            docstr = documentPackages.toString();
        }
        return "Order{" +
                "id=" + id +
                ", createdAt=" + createdAt +
                ", name='" + name + '\'' +
                //... другие поля
                ", documentPackages=" + docstr +
                '}';
    }

Как я понимаю, если коллекция documentPackages не загружена, у нее будет значение IndirectList, а не null. Статус загрузки свойства можно проверить с помощью метода EntityStates#isLoaded.

Да, проверил, там не null, но все же как тогда подгружать пустой IndirectList, если в бд есть значения

IndirectList реализует логику ленивой загрузки. При вызове dataManager...list() список documentPackages не загружается, он загружается при первом обращении к свойству documentPackages (например, при вызове исходного варианта toString или при просмотре значения свойства в режиме отладки).

Т.е. предположительно Ваше решение работает корректно, записи documentPackages не будут загружаться из БД, если не обращаться к свойству.

1 симпатия

Хорошо, спасибо, что объяснили, а проблема может быть в версии jmix?

… проблема может быть в версии jmix?

Проблема, что documentPackages загружается при отсутствии обращений к свойству? В принципе может, можно поискать похожие issues на GitHub.

@ggolubev, здравствуйте!

Как правильно объяснил @danila.daring , возможно, где-то происходит неявное обращение к свойству, что вызывает ленивую загрузку.

Имеет смысл включить logging.level.eclipselink.logging.sql = debug, чтобы логировать sql-запросы и посмотреть, в какой именно момент загружаются documentPackages.

При этом лучше не использовать режим отладки, так как даже просто остановка в области видимости переменной может вызвать ее отображение в дебагере, а Idea по умолчанию будет отображать в режиме коллекции (а не использовать toString), вычисляя и показывая ее размер. Это приводит к срабатыванию ленивой загрузки. Если очень нужно, такого поведения можно избежать, настроив отображение примерно как в конце этого ответа.

Так же обязательно для проверки использовать EntityStates#isLoaded.

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

С уважением,
Дмитрий

Добрый день! проблема правда была в логировании, а именно в toString методе, который подкачивал дополнительно, отрубив с помощью @ToString.Exclude поле удалось решить проблему, спасибо за уделенное время!