Когда использовать EntityManager.find () vs EntityManager.getReference () с JPA

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

поскольку вы не можете удалить неуправляемый объект, просто глупо загружать все поля с помощью find(...) или createQuery(...), только чтобы немедленно удалить его.

MyLargeObject myObject = em.getReference(MyLargeObject.class, objectId);
em.remove(myObject);

как я объяснил в в этой статье, если у вас есть родитель Post сущность и ребенка PostComment как показано на следующей схеме:

если вы называете find при попытке установить @ManyToOne

это заставляет меня задуматься, когда целесообразно использовать EntityManager.getReference() метод вместо этого EntityManager.найти() метод?

EntityManager.getReference() это действительно метод, подверженный ошибкам, и на самом деле очень мало случаев, когда клиентский код должен его использовать.
Лично мне никогда не нужно было его использовать.

EntityManager.getReference () и EntityManager.find (): нет разницы с точки зрения накладных расходов

я не согласен с принятый ответ и в частности:

если я называю найти метод, поставщик JPA, за кулисами, вызовет

SELECT NAME, AGE FROM PERSON WHERE PERSON_ID = ?

UPDATE PERSON SET AGE = ? WHERE PERSON_ID = ?

если я называю getReference метод, поставщик JPA, за кулисами, будет звоните

UPDATE PERSON SET AGE = ? WHERE PERSON_ID = ?

это не то поведение, которое я получаю с Hibernate 5 и javadoc из getReference() не говорит такого:

получить экземпляр, состояние которого может быть лениво притащили. Если запрошенный экземпляра не существует в базе данных, EntityNotFoundException выбрасывается при первом обращении к состоянию экземпляра. (Стойкость среда выполнения поставщика может создать исключение EntityNotFoundException когда вызывается getReference.) Приложение не должно ожидать, что состояние экземпляра будет доступно при отсоединении, если оно не было доступ к приложению, когда диспетчер сущностей был открыт.

EntityManager.getReference() запасные части a запрос для получения сущности в двух случаях:

1) если сущность хранится в контексте сохранения, то есть кэш первого уровня.
И это поведение не является специфичным для EntityManager.getReference(), EntityManager.find() также сохранит запрос для извлечения сущности, если сущность хранится в контексте сохраняемости.

вы можете проверить первый пункт с любым примером.
Вы также можете полагаться на фактическую реализацию Hibernate.
Действительно,EntityManager.getReference() опирается на createProxyIfNecessary() метод org.hibernate.event.internal.DefaultLoadEventListener класс для загрузки объекта.
Вот его реализация:

private Object createProxyIfNecessary(
        final LoadEvent event,
        final EntityPersister persister,
        final EntityKey keyToLoad,
        final LoadEventListener.LoadType options,
        final PersistenceContext persistenceContext) {
    Object existing = persistenceContext.getEntity( keyToLoad );
    if ( existing != null ) {
        // return existing object or initialized proxy (unless deleted)
        if ( traceEnabled ) {
            LOG.trace( "Entity found in session cache" );
        }
        if ( options.isCheckDeleted() ) {
            EntityEntry entry = persistenceContext.getEntry( existing );
            Status status = entry.getStatus();
            if ( status == Status.DELETED || status == Status.GONE ) {
                return null;
            }
        }
        return existing;
    }
    if ( traceEnabled ) {
        LOG.trace( "Creating new proxy for entity" );
    }
    // return new uninitialized proxy
    Object proxy = persister.createProxy( event.getEntityId(), event.getSession() );
    persistenceContext.getBatchFetchQueue().addBatchLoadableEntityKey( keyToLoad );
    persistenceContext.addProxy( keyToLoad, proxy );
    return proxy;
}

интересная часть:

Object existing = persistenceContext.getEntity( keyToLoad );

2) Если мы не эффективно манипулировать сущностью, Эхо к лениво извлечена из javadoc.
Действительно, для обеспечения эффективной загрузки объекта требуется вызов метода на нем.
Таким образом, выигрыш будет связан со сценарием, в котором мы хотим загрузить объект, не имея необходимость его использовать ? В рамках приложений эта потребность действительно необычна и, кроме того,getReference() поведение также очень вводит в заблуждение, если Вы читаете следующую часть.

почему предпочтение EntityManager.найти () над EntityManager.getReference()

С точки зрения накладных расходов, getReference() не лучше, чем find() как обсуждалось в предыдущем пункте.
Так зачем же использовать то или другое ?

вызов getReference() может вернуть лениво принесенный сущность.
Здесь ленивая выборка относится не к отношениям сущности, а к самой сущности.
Это означает, что если мы вызываем getReference() и тогда контекст сохранения закрыт, сущность может никогда не загружаться, и поэтому результат действительно непредсказуем. Например, если прокси-объект сериализован, вы можете получить null ссылка как сериализованный результат или если метод вызывается на прокси-объект, исключение, например LazyInitializationException бросается.

это означает вот это бросок EntityNotFoundException это основная причина для использования getReference() для обработки экземпляра, который не существует в базе данных, поскольку ситуация ошибки может никогда не выполняться, пока сущность не существует.

EntityManager.find() не имеет амбиций бросать EntityNotFoundException если объект не найден. Его поведение является одновременно простым и ясным. Вы никогда не будете удивлены, как он возвращает всегда загруженный объект или null (если сущность не найдена) , но никогда не является сущностью под формой прокси-сервер, который не может быть эффективно загружен.
Так что EntityManager.find() следует отдавать предпочтение в большинстве случаев.