I've been pulling my hair out all day on this problem and am severely in need of help here. I cannot figure out how to get Hibernate to assign default values to columns when it creates objects. I have searched and found many ideas and leads, but all of them have turned out to be dead ends.

Let's use this simplified table as an example:

CREATE TABLE fred
(
waldo boolean DEFAULT false
);

When I use Hibernate tools to reverse-engineer a database schema, there is no sign of the default value in the resulting mapping document. (Which, to me, is either a bug or a missing feature, but that's ancillary to the main question.)

After spending a few hours trying to figure this out and getting nowhere, I decide to edit the mapping document manually. I sacrifice automation, but I solve the immediate problem. So the property definition now looks like this:

<property name="waldo" type="java.lang.Boolean">
<column name="waldo" default="false" />
</property>

That doesn't work either; if I create an instance of Fred in the code, the waldo field stubbornly remains null.

I spent a few more hours investigating this, finding several dead ends. Eventually I run across the hackish solution described here:
http://forum.hibernate.org/viewtopic.ph ... 54#2362554

I added postProcessConfiguration to my code and traced through it as the database starts up, verifying that "false" is assigned as the column's default value.

And when I create a Fred, the waldo field still remains null!!

So I am in serious need of some expert advice to tell me what the hell is going on. I have spent a frustrating 10+ hours on this one single problem on a project that is already behind schedule. Your help is greatly appreciated.

Hibernate version: 3.2.6
Database version: PostgreSQL 8.3

I don't really know much about the default property, but it looks like it wants a SQL expression. You could try but honestly I have no idea if that will work.

Another hackish solution might be to assign the default value of waldo in Freds constructor.

doesn't work.

Assigning the default value in the constructor itself sounds like the best solution for now, but it's still not satisfactory. Can any Hibernate gurus offer advice?

Come on, anybody? Please?

This has not been a very encouraging experience. A single suggestion is far from what I expected when I registered on this forum. :-/

The issue here appears to be one of perception. NULL is a valid column value. Default values aren't used when a column value is NULL; they're used when the column isn't included in the INSERT statement or when the DEFAULT keyword is used (this has nothing to do w/ Hibernate...it's SQL..). But you've mapped the property to a column, so why would Hibernate NOT include the column in the generated INSERT statement and why would hibernate not set the value to null (which is the property's current value). Most would argue it to be a bug for Hibernate to exclude a NULL property from the generated INSERT statement (how would one validly set a column value to null in that case).

sidenote -- <property insert="false"/> will exclude the column from generated INSERT statements thus using the default value all the time. This probably isn't what you want (it feels like you only want the default value to be used when the property value is NULL).

The correct way to handle this is the one you find unsatisfactory -- to set the value of the property itself thus allowing Hibernate do it's job (that is, to persist the Object's state to the database). Perhaps this is a valid automation issue...should tools understand table default values and generate java classes that are consistant (to me, this seems consistant w/ the spirit of mapping legacy tables).

That said, if you maintain this is still wrong, then it may be possible to specify a <sql-insert> command that overrides what Hibernate generates. I can't figure out a way I know would work w/out resorting to a stored proc, but the concept is like:

INSERT INTO fred (waldo) VALUES COALESCE(?, DEFAULT)

(doubt this is valid SQL...)

note that the DB is changing the value to be something other than the current property value, so don't expect the Object to become aware of the new value unless you re-read it.