Hi,

I wonder which way to go with the [B/b]oolean choice in Hibernate.

My Dao layer is built using the Criteria API.

At first, I took the boolean way, the primitive type.

It worked fine.

I could have a Criteria that looked like:



But then, I read that it's better to take the Boolean way, the complex type.

And so, the property is then nullable.

A "false" might contain the false value or the null value.

A "true" does contain the true value.

Therefore, when checking against "false" values, the Criteria needs to check for both false and null values.



And when retrieving a value as in:



the following assertion might be failing if the value is null instead of false:



and this one might succeed:



In the second way, I therefore end up with a more complex Criteria, and an uncertainty, that is, two possible values for a "false", either false or null.

What do you think ?

Which [B/b]oolean way would you go ?

Cheers,

Use a 'boolean'. Only use 'Boolean' if you have a use case that needs null values that are handled different from both 'true' and 'false'. As you said, everything gets more complicated if you have both 'null' and 'false' mean the same thing.

My best example of a use case is file validation were the validation is optional since it is not implemented for all file types. I have used a Boolean were: false=the file has been checked and is not valid, true=the file has been checked and is valid, null=the file has not been checked.

Yes, use "boolean", unless your database column is really nullable.

Okay, thanks for these explanations. I shall revert to the boolean primitive type.

As an added note, I specified the boolean columns as being not null so as to avoid any NULL values stored in these boolean columns.



This was needed because the schema is also used by a PHP legacy application. Having NULL values in these boolean columns was making PHP return false on the condition:

as the not equal operator cannot be run properly on a NULL value.

Luckily, Hibernate is kind enough not to require the mapping to have a not-null='true' attribute and thus allowing the object boolean property not being set. When creating a new object, and persisting it, I therefore don't need to explicitly set all boolean properties to false, or true, I can leave them unspecified.

For numbers (Long, Integer etc) I always use Wrappers, but for booleans I always find it hard to decide which one to choose. From a practical perspective, I would choose Boolean. When using Boolean/Wrappers you can easily get NPE's when using logical conditions, like Stephaneeybert says.
(I also had a problem once where a not-null Hibernate constraint on a wrapper caused a MySQL query that performed really slow compared to without the constraint.)

The book "Java Persistence with Hibernate" uses wrappers for numbers. In the whole book, there is only one example where they use a primitive boolean (for the "admin" property of the "User" class), but the Boolean wrapper isn't used at all for entities.

I'm wondering what other experienced users think, especially those from the Hibernate team. What would be the recommended/best-practice, Anyone?

How about enum ?

i use wrappers if and only if the column can be null. otherwise always use primitieves.