[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2064?page=c...
]
Jasper Rosenberg commented on HHH-2064:
---------------------------------------
Look, I'm sure you are burnt out on clueless users, but that is no reason to be rude.
Yes, I know it is unfortunate that I haven't produced a simple test case. I work on
the Quartz project and I know how these kind of reports are super crappy.
However, rather than dwell on what you don't have, perhaps you should be happy for
what you do have, an early warning of a 3.2/3.1 regression issue!
After all, when all things are held constant other than the version of Hibernate, it
should be a pretty big red flag that something changed in 3.2 to cause the underlying
issue. Even if it is some false assumption in Spring or Jotm or whatever, it would still
be hibernate 3.2 that changed the behavior of the implicit contract and that is something
you would want to research and document for a new release at the very least.
I will spend some time this morning to see if I can produce a test case (because you asked
so nicely ;) but even if you don't hear from me again, I would suggest thinking
through the case where in the same transaction someone saves an object, deletes the
object, and then tries to retrieve it by its non-PK, and why in this case hibernate
doesn't realize it has to have executed the delete sql before the retrieval (though it
does work correctly if it is a retrieval by PK). I'm sure you must know exactly where
in the code the determination is made about whether to execute pending sql, and can look
to see if something has changed since 3.1 to no longer execute a pending delete in the
face of a retrieval by non-pk.
Best of luck!
Delete not always executing
---------------------------
Key: HHH-2064
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2064
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4
Environment: MySQL (latest stable), XP/Linux, hibernate 3.2.0.cr4, Spring 2.0-rc3
Reporter: Jasper Rosenberg
This case I just ran into works in 3.1.3 but fails in 3.2.0 Release Candidates (1-4).
In a single JTA transaction I execute unit test:
personManager.save(firstName, lastName, email, phone, password);
Person person = personManager.get(email); // Not the PK
assertNotNull(person);
personManager.delete(person); // Deletes by PK
person = personManager.get(email); // Not the PK
assertNull(person);
personManager is just a DAO that uses a Spring HibernateTemplate to call save/delete/get
on the underlying Session.
In 3.1.3, the final "assertNull(person)" succeeds.
In 3.2-RC4 it fails
Also, if I replace that final get with:
person = personManager.get(person.getId()); // Get by PK
Then the assertion succeeds.
When I turn on logging for org.hibernate.SQL, I can see in 3.2-RC4 the delete is never
executed (unlike in 3.1.3). If I had to make a total guess, I would suspect that in
3.2-RC4 the delete it only getting applied to the session cache, and never making it to
the database for some reason. Then, since the get(email) is not by primary key, it skips
the cache (where it has been removed) and finds it still in the database.
Sorry I am unable to give you a discrete case you can run to reproduce this issue (there
are a stupid number of dependencies), but hopefully this case will trigger a lightbulb to
go off for the developer who was last working in this portion of the code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira