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

[Steve Ebersole (JIRA)]

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

Steve Ebersole commented on HHH-2064:
-------------------------------------

I tend to cast a curious eye on bug reports referencing user DAO classes, especially Spring HibernateTemplate based DAOs which have a well documented history of issues with Hibernate interaction.

Sorry, but if you cant be bothered to create a simplified test case, then I cant be bothered dealing with this issue.  Look creating these simplified test cases serves 3 desireable purposes:
1) Forces *you* to isolate the problem and verify that it is indeed an issue with Hibernate (that is after all the point of a *bug report*);
2) Gives us (the developers) an way to reproduce the issue;
3) Gives us (the developers) a way to verify a fix and make sure we do not later instroduce a regression against it.

> 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