Каковы различия между различными методами сохранения в Hibernate?
В Hibernate есть несколько методов, которые так или иначе берут ваш объект и помещают его в базу данных. Каковы различия между ними, когда использовать какой, и почему нет только одного интеллектуального метода, который знает, когда и что использовать?
Методы, которые я определил до сих пор:
save()update()saveOrUpdate()saveOrUpdateCopy()merge()persist()
10 ответов
Вот мое понимание методов. В основном они основаны на 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 просто копирует все значения в постоянный экземпляр в сеансе (который будет загружен, если он еще не загружен). Входной объект не изменен. Таким образом, слияние является более общим, чем обновление, но может использовать больше ресурсов.
Как я объяснил в этой статье, вы должны предпочитать методы JPA большую часть времени, и update для задач пакетной обработки.
Объект JPA или Hibernate может находиться в одном из следующих четырех состояний:
- Переходный (Новый)
- Управляемый (Постоянный)
- отдельный
- Удалено (Удалено)
Переход из одного состояния в другое осуществляется с помощью методов EntityManager или Session.
Например, JPA EntityManager предоставляет следующие методы перехода состояния объекта.
Спящий Session реализует все JPA EntityManager методы и предоставляет некоторые дополнительные методы перехода состояния объекта, такие как save, saveOrUpdate а также update,
упорствовать
Чтобы изменить состояние сущности с Transient (New) на Managed (Persisted), мы можем использовать persist метод, предлагаемый JPA EntityManager который также наследуется Hibernate Session,
persistметод вызываетPersistEventкоторый обрабатываетсяDefaultPersistEventListenerHibernate слушатель событий.
Поэтому при выполнении следующего контрольного примера:
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 и спящий Session известны как кэш первого уровня.
При звонке persist объект присоединяется только к текущему контексту персистентности, и INSERT может быть отложено до flush называется.
Единственным исключением является генератор IDENTITY, который сразу же запускает INSERT, так как это единственный способ получить идентификатор сущности. По этой причине Hibernate не может выполнять пакетную вставку для сущностей, использующих генератор IDENTITY. Для более подробной информации по этой теме, проверьте эту статью.
Сохранить
Hibernate-специфичный save метод предшествует JPA, и он был доступен с начала проекта Hibernate.
saveметод вызываетSaveOrUpdateEventкоторый обрабатываетсяDefaultSaveOrUpdateEventListenerHibernate слушатель событий. Следовательно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который обрабатываетсяDefaultSaveOrUpdateEventListenerHibernate слушатель событий. Следовательноupdateметод эквивалентенsaveа такжеsaveOrUpdateметоды.
Чтобы увидеть, как update Метод работы рассмотрим следующий пример, который сохраняется Book объект в одной транзакции, затем он изменяет его, пока объект находится в отсоединенном состоянии, и вызывает SQL UPDATE, используя 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 Спящая аннотация, которая вызовет 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который обрабатываетсяDefaultSaveOrUpdateEventListenerHibernate слушатель событий. Следовательно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 собирается 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который обрабатываетсяDefaultMergeEventListenerHibernate слушатель событий.
Чтобы увидеть, как 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 когда вы уверены, что к текущему контексту персистентности уже не привязана ссылка на сущность и что отсоединенная сущность была изменена.
Для более подробной информации по этой теме, проверьте эту статью.
Заключение
Чтобы сохранить сущность, вы должны использовать JPA persist метод. Чтобы скопировать состояние отдельного объекта, merge должно быть предпочтительным. update Метод полезен только для задач пакетной обработки. save а также saveOrUpdate просто псевдонимы update и вы не должны, вероятно, использовать их вообще.
Некоторые разработчики называют save даже если объект уже управляется, но это ошибка и запускается избыточное событие, поскольку для управляемых объектов UPDATE автоматически обрабатывается во время сброса контекста постоянства.
Для более подробной информации, проверьте эту статью.
Эта ссылка хорошо объясняет:
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 для вас или вам нужно другое решение? Вы предпочитаете всегда использовать слияние, или предпочитаете использовать его только по мере необходимости для конкретных случаев
Я нашел хороший пример, показывающий различия между всеми методами сохранения в спящем режиме:
http://www.journaldev.com/3481/hibernate-session-merge-vs-update-save-saveorupdate-persist-example
Вкратце, по вышеуказанной ссылке:
спасти()
- Мы можем вызвать этот метод вне транзакции. Если мы используем это без транзакции, и у нас есть каскад между сущностями, то только первичная сущность будет сохранена, если мы не очистим сеанс.
- Таким образом, если есть другие объекты, сопоставленные с первичным объектом, они сохраняются во время совершения транзакции или когда мы очищаем сеанс.
сохраняются ()
- Это похоже на использование save() в транзакции, поэтому оно безопасно и заботится о любых каскадных объектах.
saveOrUpdate ()
Может использоваться с транзакцией или без нее, и точно так же, как save(), если она используется без транзакции, сопоставленные сущности не будут сохранены до, иначе мы очистим сеанс.
Результаты в запросах вставки или обновления на основе предоставленных данных. Если данные присутствуют в базе данных, выполняется запрос на обновление.
Обновить()
- Обновление Hibernate следует использовать, если мы знаем, что мы обновляем только информацию об объектах. Эта операция добавляет объект сущности в постоянный контекст, и дальнейшие изменения отслеживаются и сохраняются при фиксации транзакции.
- Следовательно, даже после вызова update, если мы установим какие-либо значения в сущности, они будут обновлены при фиксации транзакции.
слияния ()
- Слияние Hibernate может использоваться для обновления существующих значений, однако этот метод создает копию из переданного объекта сущности и возвращает ее. Возвращенный объект является частью постоянного контекста и отслеживается для любых изменений, переданный объект не отслеживается. В этом основное отличие метода merge() от всех других методов.
Также для практических примеров всего этого, пожалуйста, обратитесь к ссылке, которую я упомянул выше, она показывает примеры для всех этих различных методов.
На самом деле разница между спящим save() а также persist() методы зависит от класса генератора, который мы используем.
Если наш класс генератора назначен, то нет никакой разницы между save() а также persist() методы. Поскольку генератор "назначен" означает, что как программисту нам нужно дать значение первичного ключа для сохранения в праве базы данных [Надеюсь, вы знакомы с этой концепцией генераторов] В случае, если класс генератора не назначен, предположим, что если имя нашего класса генератора равно "Приращение" означает hibernate it self назначит значение идентификатора первичного ключа в праве базы данных [кроме назначенного генератора, hibernate используется только для обеспечения запоминания значения идентификатора первичного ключа], поэтому в этом случае, если мы вызываем save() или же persist() метод, то он будет вставлять запись в базу данных нормально, но слышать, что save() Метод может вернуть значение идентификатора первичного ключа, сгенерированное hibernate, и мы можем увидеть его
long s = session.save(k);
В этом же случае persist() никогда не вернет клиенту какую-либо ценность.
Имейте в виду, что если вы вызываете обновление для отдельного объекта, в базе данных всегда будет выполняться обновление, независимо от того, изменили вы объект или нет. Если это не то, что вы хотите, вы должны использовать 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.
Надеюсь, приведенное выше объяснение прояснило любые сомнения.