We ran across cases where a list (had correct size()) contained null objects on some of our queries.  At first we just put in a work around to ignore nulls.

However, a new use case arrived that required an auxiliary table to be populated.

Looking into the issue, the new table had a composite key with several elements.  It turns out when Hibernate is attempting to populate the object it verifies that each of the composite key elements is not null.  If it finds one that is null then it returns a null object.  The thinking is that a PK should never have a null.

Well, that’s nice rhetoric when you have a new system where you design from the ground up, including the database.  My current environment is the opposite: massive database compiled with over 20 years of data and associated changes.

The solution is to remove any element from a composite key that may be null.  In the particular case we were dealing with that was possible.  I can imagine there are other cases where that may not be possible.  It would then be pretty painful to massage the data to the form you need (not nulls) effect the change across the various applications using the data.