I have a simple table and object containing just name and description. Name is defined in the DB as not null. I have written a test trying to insert an OverheadTask with a null name. I pass it to Spring, who gets the hibernate template and saves the object. Unfortunately I am expecting a DataAccessException but I'm getting nothing. I debugged into the Spring code but nowhere is an SQL exception being thrown that a null value is trying to be inserted into a null field.

I know I can fix this by putting not-null="true" in the hibernate mapping file but I don't expect to have to do this. The database error ought to be reported.

Shouldn't it?

Hibernate version: 3.0

Mapping documents:


Code between sessionFactory.openSession() and session.close():
We are using Spring. All I am doing is:


Full stack trace of any exception that occurs: None

Name and version of the database you are using: Firebird

Did you commit the transaction? The exception won't get thrown in the saveOrUpdate - it will be thrown in the commit.

Good question, that. My colleague and I were just talking about it. Because this is a test suite, once the data has been 'inserted', we rollback the transaction in order to facilitate further tests.

However I'll reiterate that our expectation was that exceptions such as trying to insert a null value into a not-null field are thrown during the insert.

This is primarily because of the 'insert then select' scenario. it is not uncommon for an object to be created in the database and then selected again all within the same transaction. The data hasn't been committed but the insert is deemed to have been done.

Thinking about when we're not testing, if the exception isn't thrown until the commit, which is done right at the end of the whole process, then the user has potentially finished what they're doing and all of a sudden there's an exception thrown. Also in a longer business process, you might surround the insert action you're performing with a try/catch for the exception you're looking for. But if it isn't thrown until some later time, then you're code gets broken. Doesn't seem right...

Technically, its not the commit the forces the data written to the database, its the flush. So just manually flush the session.

OK, here is where I'm at with this... I think this is more appropriate for the Spring people but I am assuming that Hibernate users are also highly likely to be using Spring so maybe someone here can help...

We have decided to code the not-null="true" directive on the hibernate mapping definition.

Having done that we expect to get consistent behaviour whenever we try and do something stupid like set a not-null field to null! Whether it be via a create or via an update. Unfortunately this is not happening.

While testing the dao layer, I am testing creating an object with a null name (this is the field that should be not null).

As soon as I invoke create on my dao class, which calls hibernate's saveOrUpdate via Springs's getHibernateTemplate() I get an exception returned (this is good). This exception is of Spring's type ...hibernate3.HibernateSystemException with a cause set to an org.hibernate.PropertyValueException. OK, I can deal with that.

However I am also testing an update that sets the name to null. When I invoke the update on my dao class, which also calls hibernate's saveOrUpdate via Springs's getHibernateTemplate() I do NOT get an exception unless I also flush the session. When I flush the session I don't get the exception scenario I described above, I get an org.hibernate.PropertyValueException returned.

So I'm still unhappy that the same test using create and update do not operate in the same way (one I need to flush the Hibernate session the other I do not) and notwithstanding that I do not get consistent exceptions returned to me.

Why is this behaviour different?

Thanks, Andrew