I'm fighting with a problem with an optional component I added to my class which has a one-to-many relation inside to another table. The problem is that the component member object is never null and always at least has an empty collection of referenced instances of the mentioned second object.
Simplified the setup is as follows:



The main Problem with that is that the healthCare component also has some primitive types (insuranceNumber in the sample above) and reading the just saved Person object which had no healthCare Object set results in an "IllegalArgumentException: Can not set long field insurance_number n to null value". Of course I could simply change all members of the HealthCare object from primitives to objects but somehow this does not feel right.

Does someone know about a simple work-around so that empty collections do not prevent components from being null?

I'm using Hibernate 3.4.1.GA but switching to another version is easyly done.

Did you find a solution for this?
I am having the same problem :(

I'm also having this problem. Any solution?

The problem is in ComponentType.hydrate. It's checking all the properties for nullness and gives no special treatment to collections. Arguably, it should.

Since my collection is just a small set of strings, I'm working around it for now by exposing a separate string property that reads from and writes to the collection using a JSON array string. I mapped that property instead.

Could you please put it in the hibernate issue tracker as Feature request?

It wouldn't work for lazy-loaded collections. You'd need to query the collection tables in order to tell if the collections are empty or not. I'm not sure it's worth it.

Not to downplay what may be a legitimate bug here... but I can't help but wonder why you're modeling your classes in this way. If insuranceNumber and state are specific to an individual (due to the fact that the columns exist in the "persons" table) then why would you place these in the component class? If these properties are specific to an instance of HealthCare then I would expect them to exist in a joined table ("healthcare" or whatever) with "doctorVisits" having a foreign key reference to "healthcare" (rather than "persons").

If your requirements are simply to display a list of "doctorVisits" for an individual (assuming they have only one insurance provider), then you might want to move the state and insuranceNumber properties to Person and try something along the lines of:

If the reason for structuring your classes like this is to allow for an HQL query involving state and insuranceNumber from DoctorVisit, then add a bidirectional association from DoctorVisit to person and reference the properties as doctorVisit.person.insuranceNumber, doctorVisit.person.state, etc.


And by the way... if insurance_number is a nullable column in your table then you should most definitely declare this as a Long rather than a primitive (considering null cannot be assigned to a primitive).