Каковы различия между различными методами сохранения в Hibernate?

В Hibernate есть несколько методов, которые так или иначе берут ваш объект и помещают его в базу данных. Каковы различия между ними, когда использовать какой, и почему нет только одного интеллектуального метода, который знает, когда и что использовать?

Методы, которые я определил до сих пор:

• save()
• update()
• saveOrUpdate()
• saveOrUpdateCopy()
• merge()
• persist()

Вот мое понимание методов. В основном они основаны на API хотя я не использую все это на практике.

saveOrUpdate Вызовы сохранить или обновить в зависимости от некоторых проверок. Например, если идентификатора не существует, вызывается save. В противном случае обновление называется.

Сохранить Сохраняет сущность. Назначит идентификатор, если он не существует. Если это так, то, по сути, это обновление. Возвращает сгенерированный идентификатор объекта.

обновить Попытки сохранить сущность, используя существующий идентификатор. Если идентификатора не существует, я полагаю, что выдается исключение.

saveOrUpdateCopy Это устарело и больше не должно использоваться. Вместо этого есть ...

Слияние Теперь, когда мои знания начинают давать сбои. Здесь важна разница между временными, обособленными и постоянными объектами. Для получения дополнительной информации о состояниях объекта, посмотрите здесь . С помощью сохранения и обновления вы имеете дело с постоянными объектами. Они связаны с сеансом, поэтому Hibernate знает, что изменилось. Но когда у вас есть временный объект, сеанс не включается. В этих случаях вам нужно использовать слияние для обновлений и сохранять для сохранения.

persist Как упоминалось выше, это используется для временных объектов. Он не возвращает сгенерированный идентификатор.

╔══════════════╦═══════════════════════════════╦════════════════════════════════╗
║    METHOD    ║            TRANSIENT          ║            DETACHED            ║
╠══════════════╬═══════════════════════════════╬════════════════════════════════╣
║              ║       sets id if doesn't      ║   sets new id even if object   ║
║    save()    ║     exist, persists to db,    ║    already has it, persists    ║
║              ║    returns attached object    ║ to DB, returns attached object ║
╠══════════════╬═══════════════════════════════╬════════════════════════════════╣
║              ║       sets id on object       ║             throws             ║
║   persist()  ║     persists object to DB     ║       PersistenceException     ║
║              ║                               ║                                ║
╠══════════════╬═══════════════════════════════╬════════════════════════════════╣
║              ║                               ║                                ║
║   update()   ║           Exception           ║     persists and reattaches    ║
║              ║                               ║                                ║
╠══════════════╬═══════════════════════════════╬════════════════════════════════╣
║              ║  copy the state of object in  ║    copy the state of obj in    ║
║    merge()   ║     DB, doesn't attach it,    ║      DB, doesn't attach it,    ║
║              ║    returns attached object    ║     returns attached object    ║
╠══════════════╬═══════════════════════════════╬════════════════════════════════╣
║              ║                               ║                                ║
║saveOrUpdate()║           as save()           ║            as update()         ║
║              ║                               ║                                ║
╚══════════════╩═══════════════════════════════╩════════════════════════════════╝

• Смотрите Hibernate Forum для объяснения тонких различий между сохранением и сохранением. Похоже, разница в том, когда в конечном итоге выполняется оператор INSERT. Так как save возвращает идентификатор, оператор INSERT должен выполняться немедленно, независимо от состояния транзакции (что, как правило, плохо). Persist не будет выполнять какие-либо операторы вне текущей выполняемой транзакции только для назначения идентификатора. Save / Persist работают как с временными экземплярами , то есть с экземплярами, которым еще не назначен идентификатор, и как таковые они не сохраняются в БД.

• Update и Merge работают с отдельными экземплярами , то есть с экземплярами, которые имеют соответствующую запись в БД, но которые в настоящее время не присоединены (или не управляются) к сеансу. Разница между ними заключается в том, что происходит с экземпляром, который передается функции. update пытается повторно присоединить экземпляр, это означает, что в данный момент не должно быть другого экземпляра постоянного объекта, присоединенного к сеансу, в противном случае выдается исключение. Однако merge просто копирует все значения в постоянный экземпляр в сеансе (который будет загружен, если он еще не загружен). Входной объект не изменен. Таким образом, слияние является более общим, чем обновление, но может использовать больше ресурсов.

Эта ссылка хорошо объясняет:

http://www.stevideter.com/2008/12/07/saveorupdate-versus-merge-in-hibernate/

У всех нас есть те проблемы, с которыми мы сталкиваемся достаточно редко, поэтому, когда мы видим их снова, мы знаем, что решили это, но не можем вспомнить как.

NonUniqueObjectException, выброшенное при использовании Session.saveOrUpdate () в Hibernate, является одним из моих. Я буду добавлять новые функции в сложное приложение. Все мои юнит-тесты работают нормально. Затем, тестируя пользовательский интерфейс, пытаясь сохранить объект, я начинаю получать исключение с сообщением «другой объект с таким же значением идентификатора уже был связан с сеансом». Вот пример кода из Java Persistence с Hibernate.

            Session session = sessionFactory1.openSession();
            Transaction tx = session.beginTransaction();
            Item item = (Item) session.get(Item.class, new Long(1234));
            tx.commit();
            session.close(); // end of first session, item is detached

            item.getId(); // The database identity is "1234"
            item.setDescription("my new description");
            Session session2 = sessionFactory.openSession();
            Transaction tx2 = session2.beginTransaction();
            Item item2 = (Item) session2.get(Item.class, new Long(1234));
            session2.update(item); // Throws NonUniqueObjectException
            tx2.commit();
            session2.close();

Чтобы понять причину этого исключения, важно понять отдельные объекты и что происходит, когда вы вызываете saveOrUpdate () (или просто update ()) для отдельного объекта.

Когда мы закрываем отдельный сеанс Hibernate, постоянные объекты, с которыми мы работаем, отсоединяются. Это означает, что данные все еще находятся в памяти приложения, но Hibernate больше не отвечает за отслеживание изменений в объектах.

Если мы затем изменим наш отсоединенный объект и захотим обновить его, мы должны снова присоединить объект. В ходе этого процесса присоединения Hibernate проверит наличие других копий того же объекта. Если он что-то находит, он должен сказать нам, что больше не знает, что такое «настоящая» копия. Возможно, другие изменения были внесены в те другие копии, которые мы ожидаем сохранить, но Hibernate не знает о них, потому что в то время не управлял ими.

Вместо сохранения, возможно, неверных данных, Hibernate сообщает нам о проблеме через исключение NonUniqueObjectException.

Так что же нам делать? В Hibernate 3 у нас есть merge () (в Hibernate 2 используйте saveOrUpdateCopy ()). Этот метод заставит Hibernate скопировать любые изменения из других отдельных экземпляров в экземпляр, который вы хотите сохранить, и, таким образом, объединит все изменения в памяти перед сохранением.

        Session session = sessionFactory1.openSession();
        Transaction tx = session.beginTransaction();
        Item item = (Item) session.get(Item.class, new Long(1234));
        tx.commit();
        session.close(); // end of first session, item is detached

        item.getId(); // The database identity is "1234"
        item.setDescription("my new description");
        Session session2 = sessionFactory.openSession();
        Transaction tx2 = session2.beginTransaction();
        Item item2 = (Item) session2.get(Item.class, new Long(1234));
        Item item3 = session2.merge(item); // Success!
        tx2.commit();
        session2.close();

Важно отметить, что слияние возвращает ссылку на недавно обновленную версию экземпляра. Это не присоединение предмета к сессии. Если вы проверите на равенство экземпляров (item == item3), вы обнаружите, что в этом случае он возвращает false. С этого момента вы, вероятно, захотите поработать с item3.

Также важно отметить, что Java Persistence API (JPA) не имеет концепции отдельных и повторно присоединенных объектов и использует EntityManager.persist () и EntityManager.merge ().

В целом я обнаружил, что при использовании Hibernate saveOrUpdate () обычно достаточно для моих нужд. Обычно мне нужно использовать слияние только тогда, когда у меня есть объекты, которые могут иметь ссылки на объекты того же типа. Совсем недавно причина исключения была в коде, подтверждающем, что ссылка не была рекурсивной. Я загружал тот же объект в мою сессию как часть проверки, вызывая ошибку.

Где вы столкнулись с этой проблемой? Работает ли Merge для вас или вам нужно другое решение? Вы предпочитаете всегда использовать слияние, или предпочитаете использовать его только по мере необходимости для конкретных случаев

На самом деле разница между hibernate save()и persist()методами зависит от класса генератора, который мы используем.

Если наш класс генератора назначен, то нет разницы между методами save()а persist(). Поскольку генератор «назначен» означает, что как программисту нам нужно дать значение первичного ключа для сохранения в праве на базу данных [Надеюсь, вы знакомы с этой концепцией генераторов] В случае, если класс генератора не назначен, предположим, что если имя нашего класса генератора равно «Приращение» означает hibernate it self назначит значение идентификатора первичного ключа в праве базы данных [кроме назначенного генератора, hibernate используется только для обеспечения запоминания значения идентификатора первичного ключа], поэтому в этом случае, если мы вызовем метод save()или persist()метод, он вставит запись в база данных в норме. Но, слышим, save()метод может возвращать значение идентификатора первичного ключа, сгенерированное hibernate, и мы можем увидеть его

long s = session.save(k);

В этом же случае persist()никогда не вернет клиенту никакого значения.

Я нашел хороший пример, показывающий различия между всеми методами сохранения в спящем режиме:

http://www.journaldev.com/3481/hibernate-session-merge-vs-update-save-saveorupdate-persist-example

Вкратце, по вышеуказанной ссылке:

спасти()

• Мы можем вызвать этот метод вне транзакции. Если мы используем это без транзакции, и у нас есть каскад между сущностями, то сохраняется только основная сущность, если мы не очистим сеанс.
• Таким образом, если есть другие объекты, сопоставленные с первичным объектом, они сохраняются во время совершения транзакции или когда мы очищаем сеанс.

сохраняются ()

• Это похоже на использование save () в транзакции, поэтому оно безопасно и заботится о любых каскадных объектах.

saveOrUpdate ()

• Может использоваться с транзакцией или без нее, и точно так же, как save (), если она используется без транзакции, сопоставленные сущности не будут сохранены до, иначе мы сбросим сеанс.

• Результаты в запросах вставки или обновления на основе предоставленных данных. Если данные присутствуют в базе данных, выполняется запрос на обновление.

Обновить()

• Обновление Hibernate следует использовать, если мы знаем, что мы обновляем только информацию об объектах. Эта операция добавляет объект сущности в постоянный контекст, и дальнейшие изменения отслеживаются и сохраняются при фиксации транзакции.
• Следовательно, даже после вызова update, если мы установим какие-либо значения в сущности, они будут обновлены при фиксации транзакции.

слияния ()

• Слияние Hibernate может использоваться для обновления существующих значений, однако этот метод создает копию из переданного объекта сущности и возвращает ее. Возвращенный объект является частью постоянного контекста и отслеживается для любых изменений, переданный объект не отслеживается. В этом основное отличие метода merge () от всех других методов.

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

Как я объяснил в этой статье , вы должны предпочитать методы JPA большую часть времени, иupdate для задач пакетной обработки.

Объект JPA или Hibernate может находиться в одном из следующих четырех состояний:

• Переходный (Новый)
• Управляемый (Постоянный)
• отдельный
• Удалено (Удалено)

Переход из одного состояния в другое осуществляется с помощью методов EntityManager или Session.

Например, JPA EntityManagerпредоставляет следующие методы перехода состояния объекта.

Hibernate Sessionреализует все EntityManagerметоды JPA и предоставляет некоторые дополнительные методы перехода состояния объекта, такие как save, saveOrUpdateи update.

упорствовать

Чтобы изменить состояние сущности с Transient (New) на Managed (Persisted), мы можем использовать persistметод, предложенный JPA, EntityManagerкоторый также наследуется Hibernate Session.

persistМетод вызывает , PersistEventкоторый обрабатывается DefaultPersistEventListenerпрослушивателя событий гибернации.

Поэтому при выполнении следующего теста:

doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    entityManager.persist(book);

    LOGGER.info(
        "Persisting the Book entity with the id: {}", 
        book.getId()
    );
});

Hibernate генерирует следующие операторы SQL:

CALL NEXT VALUE FOR hibernate_sequence

-- Persisting the Book entity with the id: 1

INSERT INTO book (
    author, 
    isbn, 
    title, 
    id
) 
VALUES (
    'Vlad Mihalcea', 
    '978-9730228236', 
    'High-Performance Java Persistence', 
    1
)

Обратите внимание, что объект idназначается до присоединения Bookобъекта к текущему контексту постоянства. Это необходимо, потому что управляемые объекты хранятся в Mapструктуре, где ключ формируется типом объекта и его идентификатором, а значение является ссылкой на объект. По этой причине JPA EntityManagerи Hibernate Sessionизвестны как кэш первого уровня.

При вызове persistсущность присоединяется только к текущему контексту постоянства, и INSERT может быть отложено доflush .

Единственным исключением является генератор IDENTITY, который сразу же запускает INSERT, поскольку это единственный способ получить идентификатор сущности. По этой причине Hibernate не может выполнять пакетную вставку для объектов, использующих генератор IDENTITY. Для более подробной информации по этой теме, проверьте эту статью .

Сохранить

Специфичный для Hibernate saveметод предшествует JPA, и он доступен с начала проекта Hibernate.

saveМетод вызывает , SaveOrUpdateEventкоторый обрабатывается DefaultSaveOrUpdateEventListenerпрослушивателя событий гибернации. Таким образом, saveметод эквивалентен updateи saveOrUpdateметоды.

Чтобы увидеть, как saveработает метод, рассмотрим следующий тестовый пример:

doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    Session session = entityManager.unwrap(Session.class);

    Long id = (Long) session.save(book);

    LOGGER.info(
        "Saving the Book entity with the id: {}", 
        id
    );
});

При выполнении приведенного выше теста Hibernate генерирует следующие операторы SQL:

CALL NEXT VALUE FOR hibernate_sequence

-- Saving the Book entity with the id: 1

INSERT INTO book (
    author, 
    isbn, 
    title, 
    id
) 
VALUES (
    'Vlad Mihalcea', 
    '978-9730228236', 
    'High-Performance Java Persistence', 
    1
)

Как видите, результат идентичен persistвызову метода. Однако, в отличие от этого persist, saveметод возвращает идентификатор объекта.

Для более подробной информации, проверьте эту статью .

Обновить

Специфичный для Hibernate updateметод предназначен для обхода механизма грязной проверки и принудительного обновления сущности во время сброса.

updateМетод вызывает , SaveOrUpdateEventкоторый обрабатывается DefaultSaveOrUpdateEventListenerпрослушивателя событий гибернации. Таким образом, updateметод эквивалентен saveи saveOrUpdateметоды.

Чтобы увидеть, как updateработает метод, рассмотрим следующий пример, в котором Bookсущность сохраняется в одной транзакции, затем она модифицирует ее, пока сущность находится в отсоединенном состоянии, и updateвызывает SQL UPDATE, используя вызов метода.

Book _book = doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    entityManager.persist(book);

    return book;
});

LOGGER.info("Modifying the Book entity");

_book.setTitle(
    "High-Performance Java Persistence, 2nd edition"
);

doInJPA(entityManager -> {
    Session session = entityManager.unwrap(Session.class);

    session.update(_book);

    LOGGER.info("Updating the Book entity");
});

При выполнении приведенного выше теста Hibernate генерирует следующие операторы SQL:

CALL NEXT VALUE FOR hibernate_sequence

INSERT INTO book (
    author, 
    isbn, 
    title, 
    id
) 
VALUES (
    'Vlad Mihalcea', 
    '978-9730228236', 
    'High-Performance Java Persistence', 
    1
)

-- Modifying the Book entity
-- Updating the Book entity

UPDATE 
    book 
SET 
    author = 'Vlad Mihalcea', 
    isbn = '978-9730228236', 
    title = 'High-Performance Java Persistence, 2nd edition'
WHERE 
    id = 1

Обратите внимание, что UPDATEвыполняется во время сброса Постоянного контекста, непосредственно перед фиксацией, и поэтому Updating the Book entityсообщение регистрируется первым.

Использование, @SelectBeforeUpdateчтобы избежать ненужных обновлений

Теперь ОБНОВЛЕНИЕ всегда будет выполняться, даже если объект не был изменен в отключенном состоянии. Чтобы предотвратить это, вы можете использовать @SelectBeforeUpdateаннотацию Hibernate, которая будет вызывать SELECTоператор, который получилloaded state который затем используется механизмом грязной проверки.

Итак, если мы аннотируем Bookсущность с @SelectBeforeUpdateаннотацией:

@Entity(name = "Book")
@Table(name = "book")
@SelectBeforeUpdate
public class Book {

    //Code omitted for brevity
}

И выполните следующий контрольный пример:

Book _book = doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    entityManager.persist(book);

    return book;
});

doInJPA(entityManager -> {
    Session session = entityManager.unwrap(Session.class);

    session.update(_book);
});

Hibernate выполняет следующие операторы SQL:

INSERT INTO book (
    author, 
    isbn, 
    title, 
    id
) 
VALUES (
    'Vlad Mihalcea', 
    '978-9730228236', 
    'High-Performance Java Persistence', 
    1
)

SELECT 
    b.id,
    b.author AS author2_0_,
    b.isbn AS isbn3_0_,
    b.title AS title4_0_
FROM 
    book b
WHERE 
    b.id = 1

Обратите внимание, что на этот раз не UPDATEвыполняется, так как механизм грязной проверки Hibernate обнаружил, что объект не был изменен.

SaveOrUpdate

Специфичный для Hibernate saveOrUpdateметод - это просто псевдоним для saveи update.

saveOrUpdateМетод вызывает , SaveOrUpdateEventкоторый обрабатывается DefaultSaveOrUpdateEventListenerпрослушивателя событий гибернации. Таким образом, updateметод эквивалентен saveи saveOrUpdateметоды.

Теперь вы можете использовать, saveOrUpdateкогда хотите сохранить сущность или форсировать, UPDATEкак показано в следующем примере.

Book _book = doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    Session session = entityManager.unwrap(Session.class);
    session.saveOrUpdate(book);

    return book;
});

_book.setTitle("High-Performance Java Persistence, 2nd edition");

doInJPA(entityManager -> {
    Session session = entityManager.unwrap(Session.class);
    session.saveOrUpdate(_book);
});

Остерегайтесь NonUniqueObjectException

Одна из проблем, которая может возникнуть при использовании save, updateи saveOrUpdateзаключается в том, что контекст постоянства уже содержит ссылку на сущность с тем же идентификатором и того же типа, что и в следующем примере:

Book _book = doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    Session session = entityManager.unwrap(Session.class);
    session.saveOrUpdate(book);

    return book;
});

_book.setTitle(
    "High-Performance Java Persistence, 2nd edition"
);

try {
    doInJPA(entityManager -> {
        Book book = entityManager.find(
            Book.class, 
            _book.getId()
        );

        Session session = entityManager.unwrap(Session.class);
        session.saveOrUpdate(_book);
    });
} catch (NonUniqueObjectException e) {
    LOGGER.error(
        "The Persistence Context cannot hold " +
        "two representations of the same entity", 
        e
    );
}

Теперь, выполняя приведенный выше тестовый пример, Hibernate собирается выбросить a, NonUniqueObjectExceptionпотому что второй EntityManagerуже содержит Bookсущность с тем же идентификатором, что и тот, который мы передаем update, и контекст постоянства не может содержать два представления одной и той же сущности.

org.hibernate.NonUniqueObjectException: 
    A different object with the same identifier value was already associated with the session : [com.vladmihalcea.book.hpjp.hibernate.pc.Book#1]
    at org.hibernate.engine.internal.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:651)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:284)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:227)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:92)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:73)
    at org.hibernate.internal.SessionImpl.fireSaveOrUpdate(SessionImpl.java:682)
    at org.hibernate.internal.SessionImpl.saveOrUpdate(SessionImpl.java:674)

Объединить

Чтобы избежать этого NonUniqueObjectException, вам нужно использовать mergeметод, предложенный JPA EntityManagerи унаследованный Hibernate Session.

Как объясняется в этой статье , mergeвыборочный снимок новой сущности извлекается из базы данных, если в контексте постоянства не найдена ссылка на сущность, и копирует состояние отсоединенной сущности, переданной mergeметоду.

mergeМетод вызывает , MergeEventкоторый обрабатывается DefaultMergeEventListenerпрослушивателя событий гибернации.

Чтобы увидеть, как mergeработает метод, рассмотрим следующий пример, в котором Bookобъект сохраняется в одной транзакции, затем он модифицирует его, пока объект находится в отключенном состоянии, и передает отсоединенный объект mergeв контекст постоянства подпоследовательности.

Book _book = doInJPA(entityManager -> {
    Book book = new Book()
    .setIsbn("978-9730228236")
    .setTitle("High-Performance Java Persistence")
    .setAuthor("Vlad Mihalcea");

    entityManager.persist(book);

    return book;
});

LOGGER.info("Modifying the Book entity");

_book.setTitle(
    "High-Performance Java Persistence, 2nd edition"
);

doInJPA(entityManager -> {
    Book book = entityManager.merge(_book);

    LOGGER.info("Merging the Book entity");

    assertFalse(book == _book);
});

При выполнении приведенного выше теста Hibernate выполнил следующие операторы SQL:

INSERT INTO book (
    author, 
    isbn, 
    title, 
    id
) 
VALUES (
    'Vlad Mihalcea', 
    '978-9730228236', 
    'High-Performance Java Persistence', 
    1
)

-- Modifying the Book entity

SELECT 
    b.id,
    b.author AS author2_0_,
    b.isbn AS isbn3_0_,
    b.title AS title4_0_
FROM 
    book b
WHERE 
    b.id = 1

-- Merging the Book entity

UPDATE 
    book 
SET 
    author = 'Vlad Mihalcea', 
    isbn = '978-9730228236', 
    title = 'High-Performance Java Persistence, 2nd edition'
WHERE 
    id = 1

Обратите внимание, что ссылка на сущность, возвращаемая объектом, mergeотличается от той, которую мы передали mergeметоду.

Теперь, хотя вы предпочитаете использовать JPA mergeпри копировании состояния отсоединенной сущности, дополнительное SELECTможет быть проблематичным при выполнении задачи пакетной обработки.

По этой причине вы должны предпочесть использовать, updateесли вы уверены, что к текущему контексту персистентности уже не привязана ссылка на сущность и что отсоединенная сущность была изменена.

Для более подробной информации по этой теме, проверьте эту статью .

Вывод

Чтобы сохранить сущность, вы должны использовать persistметод JPA . Чтобы скопировать состояние отдельного объекта, mergeдолжно быть предпочтительным. Этот updateметод полезен только для задач пакетной обработки. saveИ saveOrUpdateпросто псевдонимы , updateи вы не должны , вероятно , использовать их на всех.

Некоторые разработчики вызывают saveдаже тогда, когда сущность уже управляется, но это ошибка и вызывает избыточное событие, поскольку для управляемых сущностей UPDATE автоматически обрабатывается во время сброса контекста постоянства.

Для более подробной информации, проверьте эту статью .

Имейте в виду, что если вы вызываете обновление для отдельного объекта, в базе данных всегда будет выполняться обновление независимо от того, изменили вы объект или нет. Если это не то, что вы хотите, вы должны использовать Session.lock () с LockMode.None.

Вы должны вызывать update, только если объект был изменен вне области текущего сеанса (в автономном режиме).

Ни один из следующих ответов не является правильным. Все эти методы кажутся похожими, но на практике делают совершенно разные вещи. Трудно давать короткие комментарии. Лучше дать ссылку на полную документацию об этих методах: http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/objectstate.html

Ни один из ответов выше не является полным. Хотя ответ Лео Теобальда выглядит ближайшим ответом.

Суть в том, как hibernate работает с состояниями сущностей и как он обрабатывает их при изменении состояния. Все должно быть рассмотрено и в отношении сбрасываний и коммитов, которые, кажется, все полностью проигнорировали.

НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЭКОНОМИЧЕСКИЙ МЕТОД HIBERNATE. ЗАБУДЬТЕ, ЧТО ЭТО ДАЖЕ СУЩЕСТВУЕТ В HIBERNATE!

упорствовать

Как все объяснили, Persist в основном переводит сущность из «переходного» состояния в «управляемое» состояние. На этом этапе слякоть или коммит могут создать оператор вставки. Но сущность все равно останется в «Управляемом» состоянии. Это не меняется с флешем.

В этот момент, если вы снова «упорствуете», никаких изменений не будет. И больше не будет спасений, если мы попытаемся сохранить существующую сущность.

Веселье начинается, когда мы пытаемся выселить сущность.

Выселение - это специальная функция Hibernate, которая переводит сущность из «Управляемого» в «Отделенный». Мы не можем вызвать упорство на отдельном объекте. Если мы это сделаем, то Hibernate вызовет исключение, и вся транзакция будет откатана при фиксации.

Слияние с обновлением

Это две интересные функции, которые делают разные вещи, когда рассматриваются по-разному. Оба они пытаются перевести сущность из состояния «Отключено» в состояние «Управляемый». Но делать это по-другому.

Поймите факт, что Detached означает своего рода "автономное" состояние. и управляемый означает «онлайн» состояние.

Соблюдайте код ниже:

Session ses1 = sessionFactory.openSession();

    Transaction tx1 = ses1.beginTransaction();

    HibEntity entity = getHibEntity();

    ses1.persist(entity);
    ses1.evict(entity);

    ses1.merge(entity);

    ses1.delete(entity);

    tx1.commit();

Когда ты это делаешь? Как ты думаешь, что произойдет? Если вы сказали, что это вызовет исключение, то вы правы. Это вызовет исключение, потому что, слияние сработало на объекте объекта, который является отделенным состоянием. Но это не меняет состояние объекта.

За сценой слияние вызовет запрос выбора и в основном возвращает копию объекта, который находится в присоединенном состоянии. Соблюдайте код ниже:

Session ses1 = sessionFactory.openSession();

    Transaction tx1 = ses1.beginTransaction();
    HibEntity entity = getHibEntity();

    ses1.persist(entity);
    ses1.evict(entity);

    HibEntity copied = (HibEntity)ses1.merge(entity);
    ses1.delete(copied);

    tx1.commit();

Приведенный выше пример работает, потому что слияние принесло новую сущность в контекст, который находится в постоянном состоянии.

При применении с обновлением то же самое работает нормально, потому что обновление на самом деле не приносит копию объекта, как слияние.

Session ses1 = sessionFactory.openSession();

    Transaction tx1 = ses1.beginTransaction();

    HibEntity entity = getHibEntity();

    ses1.persist(entity);
    ses1.evict(entity);

    ses1.update(entity);

    ses1.delete(entity);

    tx1.commit();

В то же время в трассировке отладки мы видим, что Update не вызвал SQL-запрос select как merge.

Удалить

В приведенном выше примере я использовал удаление, не говоря об удалении. Удаление в основном переводит объект из управляемого состояния в состояние «удалено». А при сбросе или подтверждении выдаст команду удаления для сохранения.

Однако возможно вернуть объект в «управляемое» состояние из «удаленного» состояния, используя метод persist.

Надеюсь, приведенное выше объяснение прояснило любые сомнения.