NULL values ending up in Result Set from Criteria Query


As outlined in the following thread:

I have since rolled our code base back to Beta 4 and this problem does not exhibit itself.

Abriged version, executing criteria query and NULL entities are being returned by the loader. In my example, I end up with 4 NULL values and an actual record.

In Beta 4 I end up with 5 actual records. It may help to note that the 4 missing objects end up being the same record from the database. In beta 4 I pass these through the DistinctRootResultTransformer and end up with 2 distinct records.

In RC1 I end up with 1 actual record and a single NULL value. I had originally thought that passing the resultset through a custom transformer would do the trick as the NULL entities were thought to be ghosts. Turns out they are actual records.

I've abandoned RC1 for now and have gone back to Beta4.


Oracle 9i


March 5, 2005, 12:19 PM

Actually, after thinking quickly about this, I realized that there is no way that Hibernate can handle null columns in PKs, at least not on dbs which implement standard ANSI-compliant ternary logic.

So we will certainly not try to change this.

March 4, 2005, 10:04 PM

Hibernate 3 treats any key with a null value as null. This is reasonable because nulls in primary keys are completely evil and not allowed on most dbs.

Shawn Clowater
March 4, 2005, 9:42 PM

It looks to be a fairly specific issue.

In my case what is happening is that I have a comp PK on a view made up of 3 columns where one of the columns happens to be nullable. Now, under normal circumstances this shouldn't (maybe can't - don't know how 100% of db platforms behave) since the PK can't be defined on a nullable column (even if it is composite).

However, a unique constraint can be made up of a nullable column (at least under oracle) and judging by the comment made in the code that actually affects this you could end up with the same sort of results.

The code in question is in the ComponentType's hydrate method.

The code in Beta 4 read:
if ( val != null ) notNull = true;

So all columns had to be null to return a NULL row in the result set.

However, in RC1 it is now:
if ( val == null ) {
if (isKey) return null; //different nullability rules for pk/fk
else {
notNull = true;

As soon as it finds a null value for somthing deemed as a key it returns NULL for the whole row. It hints that FKs would be treated in the same manner.

For us, I'm going to look at changing our PK definition on the read only view. I'll let you guys decide if this was by design or is a bug.

Max Rydahl Andersen
March 4, 2005, 1:02 PM

runnable test case please.

Won't Fix




Shawn Clowater

Fix versions






Suitable for new contributors


Requires Release Note


Pull Request





Affects versions