[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2064) Delete not always executing

[Jasper Rosenberg (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2064?page=comments#action_24730 ] 

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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira