Собственный запрос EclipseLink и поведение FetchType

Question

Я пытаюсь понять поведение EclipseLink в случае, если я использую собственный запрос. Поэтому у меня есть Entity, как это:

class Entity { 

    @OneToOne(fetch = FetchType.LAZY) 
    @JoinColumn(name="other_entity_id") 
    private OtherEntity otherEntity; 

    @Column(name = "name") 
    private String name; 
    //gets ... sets ... 
} 

и соответствующая таблица выглядит следующим образом:

**ENTITY** 

INTEGER ID; 

VARCHAR NAME; 

OTHER_ENTITY_ID; 

А потом я бегу родной запрос

Query query = getEntityManager().runNativeQuery("select * from ENTITY", Entity.class); 
query.getResultList() 

В Entity я объявил OtherEntity otherEntity который с аннотацией FetchType.LAZY, однако мой запрос выбирает (*) - все столбцы, включая OTHER_ENTITY_ID. Вопрос в том, что - если я запускаю собственный запрос, который извлекает все столбцы, будут ли аннотированы поля FetchType.LAZY, как если бы они были FetchType.EAGER или нет? Я никогда не работал с EclipseLink до и Tyring решить, стоит ли использовать его или нет, так что я был бы очень признателен за любую помощь

Спасибо, Приветствия

Answer 1

Мой первый совет, чтобы включить ведение журнала SQL EclipseLink, и выполнить эквивалентный JPQL, чтобы загрузить то, что вы ищете, и увидеть, как SQL EclipseLink генерирует, чтобы достичь этого, чтобы понять, что требуется для создания объектов в ваших собственных запросах на основе ваших текущих сопоставлений.

Отношения, обычно загружаемые вторичным запросом с использованием значений, считанных с внешних ключей, так что нетерпимый или ленивый выбор не влияет на собственный запрос для чтения в «Сущность» - для запроса требуется значение other_entity_id независимо от выборки тип. При необходимости, исходя из нетерпимой/ленивой загрузки, EclipseLink выдаст запрос, необходимый для сопоставления.

Вы можете изменить это, отметив, что связь заключается в использовании joining. В этом случае EclipseLink ожидает в запросе не только значений Entity, но и других значений OtherEntity.