The following comment has been added to this issue:
Author: Serge Knystautas
Created: Fri, 5 Dec 2003 8:15 PM
Body:
It happened because saveOrUpdate failed, so then I dropped into the catch/finally blocks which attempted to close/flush the session. So the first exception from the saveOrUpdate got dropped as the new exception from the session flush/close block.
So if EntityEntry cannot have a null id, can we have an if in that block to test for if a null id then throw a Hibernate exception? I can see the argument that it's incorrect to flush a session when there's been a hibernate exception during that session, but a friendly error message could help a brute-force developer like me figure out what I should do instead.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-528
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-528
Summary: SessionImpl.checkId does not handle null IDs
Type: Bug
Status: Unassigned
Priority: Critical
Project: Hibernate2
Components:
core
Versions:
2.1 rc1
Assignee:
Reporter: Serge Knystautas
Created: Fri, 5 Dec 2003 10:40 AM
Updated: Fri, 5 Dec 2003 8:15 PM
Environment: Hibernate 2.1 rc1 on Resin 2.1.8, Windows XP, Sun JDK 1.4.1, and SQL Server 2000.
Description:
I hit this problem with the following steps:
1. Create a class with a native ID generator (uses an Integer, but tried with in as well).
2. Instantiate that object, set some bean properties, call saveOrUpdate on this. Do not set a bean property for something that IS marked as not-null="true". This means it should fail to persist.
3. Call saveOrUpdate on the object, which should in theory generate a new ID and save it when session flushes.
4. When session flushes, you get a null pointer exception in net.sf.hibernate.impl.SessionImpl:2519 because id is null, because it couldn't save.
The fix is to change that if comparison from
( !id.equals(oid))
to
((id == null && oid != null) || (id != null && !id.equals(oid)) )
With this in place, the checkId will now pass through cleanly (because id == oid == null), which I think is the correct behavior. The benefit is that instead of an unintelligible null pointer exception, it falls through and gives me the Flush not possible because a not-null value is null.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
