Выбрать с присоединением к произвольному типу - PullRequest
0 голосов
/ 28 мая 2020

У меня есть объекты, которые выглядят следующим образом:

@Entity
@Data
@NoArgsConstructor
@AllArgsConstructor
public class MyEntity {
    @Id
    private UUID id;

    @OneToMany(targetEntity = Relation.class, fetch = FetchType.EAGER)
    private List<Relation> relatedList;
}

@Entity
@Data
public class Relation {
    @Id
    private UUID id;
}

Кроме того, у меня есть другой тип:

@Data
public class OtherType extends MyEntity {
    private String otherField;

    public OtherType(UUID id, List<Relation> relations, String otherField) {
        super(id, relations);
        this.otherField = otherField;
    }
}

Теперь я хочу выбрать объекты в таблица MyEntity вместе с некоторой дополнительной информацией (otherField) в объект типа OtherType:

select e.id, e.relatedList, 'otherStuff' as otherField from MyEntity e

Если я использую этот запрос с HQL, он преобразует e.relatedList в . as col_x_x_, что, очевидно, является синтаксической ошибкой. Я пытался использовать собственный запрос, но это просто говорит о том, что OtherType не является Entity. Если я использую NamedNativeQuery с resultSetMapping, он не может сопоставить список значений с коллекцией (No dialect mapping for JDBC type 1111). Я также пробовал использовать функцию postgres array_agg, чтобы получить только массив идентификаторов для моего отношения, но это тоже не может быть отображено. Есть ли какой-либо способ достичь этого, кроме определения конструктора в OtherType, который принимает одно значение вместо списка, выполняя фактическое реальное соединение SQL (где каждый экземпляр Relation добавляет еще одну MyEntity строку) и сопоставить это потом?

1 Ответ

1 голос
/ 30 мая 2020

Это идеальный вариант использования Blaze-Persistence Entity Views .

Я создал библиотеку, чтобы обеспечить простое сопоставление между моделями JPA и пользовательским интерфейсом или моделями, определяемыми абстрактным классом, что-то вроде Прогнозы весенних данных на стероидах. Идея состоит в том, что вы определяете свою целевую структуру (модель домена) так, как вам нравится, и сопоставляете атрибуты (геттеры) через выражения JPQL с моделью сущности. Поскольку имя атрибута используется в качестве сопоставления по умолчанию, в большинстве случаев явные сопоставления вам не нужны, поскольку в 80% случаев использования DTO являются подмножеством модели сущности.

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

@EntityView(MyEntity.class)
public interface MyEntityView {
    @IdMapping
    UUID getId();
    String getOtherField();
    List<RelationView> getRelations();
}
@EntityView(Relation.class)
public interface RelationView {
    @IdMapping
    UUID getId();
}

Запрос - это вопрос применения представления сущности к запросу, простейшим из которых является запрос по идентификатору.

MyEntityView p = entityViewManager.find(entityManager, MyEntityView.class, id);

Интеграция Spring Data позволяет использовать ее почти как Spring Data Projection: https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#spring -data-features

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...