[
https://hibernate.onjira.com/browse/HHH-7304?page=com.atlassian.jira.plug...
]
Guenther Demetz commented on HHH-7304:
--------------------------------------
The problem is in first line not the unneccessary find-by-natural-id-query, this is surely
overhead, but not really a bug.
The real problem is indeed, that the not-caching undermines the inline natural-synch
process indroduced in hibernate4.1.2,
which relies on attached natural-id entities always having a concerning transactional
natural-id cache entry.
In fact following testcase proves the bug, as suddenly natural-id-changes are not more
recognized by the natural-id lookup:
{code:title=org.hibernate.test.jpa.naturalid.MutableNaturalIdTest.java|borderStyle=solid}
@Test
@TestForIssue( jiraKey = "HHH-7304")
public void testInLineSynchWithIdentityColumn() {
Session s = openSession();
s.beginTransaction();
ClassWithIdentityColumn e = new ClassWithIdentityColumn();
e.setName("Dampf");
s.save(e);
e.setName("Klein");
assertNotNull(session.bySimpleNaturalId(ClassWithIdentityColumn.class).load("Klein"));
session.getTransaction().rollback();
session.close();
}
{code}
Pull request is
https://github.com/hibernate/hibernate-orm/pull/332
NaturalIdResolutionCache not correctly filled on first persist when
@GeneratedValue-@Id
---------------------------------------------------------------------------------------
Key: HHH-7304
URL:
https://hibernate.onjira.com/browse/HHH-7304
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.3
Reporter: Frank Schwarz
Labels: natural-id, performance
{code:title=Employee.java|borderStyle=solid}
@Entity
public class Employee{
@Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id;
@NaturalId(mutable = true) private String name;
@NaturalId(mutable = true) private String surname;
private String position;
}
{code}
{code:title=NaturalIdTest1.java|borderStyle=solid}
entityManager.getTransaction().begin();
Employee e = new Employee();
e.setSurname("Hans");
e.setName("Dampf");
e.setPosition("Junior");
entityManager.persist(e);
entityManager.getTransaction().commit();
Session session = entityManager.unwrap(Session.class);
Employee e2 = (Employee) session.byNaturalId(Employee.class)
.using("surname", "Hans")
.using("name", "Dampf")
.load();
System.out.println(e2);
{code}
{code:title=NaturalIdTest2.java|borderStyle=solid}
entityManager.getTransaction().begin();
Employee e = new Employee();
e.setSurname("Hans");
e.setName("Dampf");
e.setPosition("Junior");
entityManager.persist(e);
// this is the only difference
e.setPosition("Senior");
entityManager.getTransaction().commit();
Session session = entityManager.unwrap(Session.class);
Employee e2 = (Employee) session.byNaturalId(Employee.class)
.using("surname", "Hans")
.using("name", "Dampf")
.load();
System.out.println(e2);
{code}
The NaturalIdTest1 will issue an SQL statement for the find-by-natural-id-query; the
NaturalIdTest2 does not.
Put a breakpoint into NaturalIdResolutionCache#cache(Serializable, Object[]) and watch
the pk-parameter to be {{null}} on the first invocation and not {{null}} on the second
invocation.
If the @Id-field is not @GeneratedValue, the first invocation of
NaturalIdResolutionCache#cache will be already correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira