My app's vital statistics:

Hibernate 2.1.2
JBoss 3.x


Question: I want to be able to generate a default value for a column. In java

/**
* @hibernate.property
* column = "foo"
* length = "6"
* not-null = "true"
* default = 'somestuff"
*/

I want a default property which will generate this DDL:

CREATE TABLE someTable {
foo VARCHAR(6) not null DEFAULT 'somestuff'
}

Thanks

Alistair

If you check the mapping DTD you will see that default is not supported (thus Xdoclet does not support it either). Create a JIRA entry and Make a request for this feature.

If your only using Hibernate to access the database then you can set the value in the Domain object(s) concerned.

I would also like to see this feature added. I created Jira entry HB-1151 regarding this.

Gavin was a little quick to close out this jira ticket. I added more comments and suggestions to it, but don't know how to reopen it for consideration.

Basically having the DB default not-null columns that are mapped to java primatives should be no problem. We should be able to have the db default booleans to false instead of NULL, ints to 0 and floats to 0.0.

0 is not NULL.

Exactly. In some cases developers want a NULL in a column. In others they do not want this.

How do I match a UI to a Boolean(true, false, NULL)? A checkbox cannot do that. If I map with an object Boolean, I have to worry about NULL, where in the majority of cases, false is sufficient.

For example if I have a boolean indicating if a user wants to be notified to certain events, I'd only notify when true, false and NULL are the same to me.

For cases like this, having the DB default to false, and setting it to not-null are very nice.

Can't edit my post to add this, so a new post.

If people want nullable columns, they can map them to Integer, Boolean, Double, etc.

If mapping to int, double, boolean, etc. NULLS cause hibernate to puke. If perl scripts, etc do occasional inserting, or if triggers/stored procs do some inserting, the java/hibernate developer cannot be assured that nulls are not present, without not-null. Having a reasonable default value makes those other scripts much easier to manage.

Too many times I've read posts from the hibernate team implying that we should just make sure all db access is through hibernate. That is not realistic.

No, what the Hibernate team says is: 0 is not NULL and Hibernate will not provide functionality to map NULL to 0. Use a custom UserType if you are sure what you are doing.

It really doesn't seem like we are on the same page. I appreciate your timely replies, but just have these questions:

1. How do YOU (personally) map booleans? If with a primative, then I think you must have a not-null constraint. If with an Object, doesn't that make your controller/UI logic more complicated?

2. Once you commit to adding a not-null constraint, how do you want your PL/SQL, perl, etc sctripts to handle inserting? Should each script know that we want to put a zero/false into these oracle columns? Isn't it much better to define that in one place, the DDL?

3. I don't really see this as hibernate functionality per se, but a feature of the hbm2ddl tool. Outside of that tool, the entire hibernate codebase could ignore the default attribute we are discussing.

4. Do you see JDK 1.5's autoboxing feature having an effect on the above three questions?

Thanks for the help,

Ted

If you have a NULL in the field, your object should be NULL. Therefore, don't use primitives if you allow NULL. As simple as this.

If you think that this complicates your UI logic, write a helper method or use autoboxing. But its simply wrong for the persistence layer to translate this automatically. If you like this behavior, there are UserTypes. Thats what they were made for.

Well, it's simple, if NULL does not have a different meaning then 0, map the column as NOT NULL.

If it does have a different meaning, map it as NULL and use objects not primitive types.

If there is a difference between 0 and NULL, the other applications must know anyways on what means what.

Ok, I wont drag this out any longer after this.

I understand your point. This is my first Hibernate app, and I am using primatives in my model layer. In most cases, I later locked down the columns with not-null constraints. At this point my code is happy.

I think you're suggesting the model layer use object types over primatives, and that I translate between the model and UI in the service layer. I will look at doing that next time around.

The DBA's are doing a data migration from our old (poor quality) schema. They are bitching because the old data is quite bad, and they are running into my not-null constraints.

They told me to put default values on this so they can do the migration. I tell them I am using hibernate for this, and it isn't supported.

DBA's come back at me asking why the hell I am using this Hibernate tool they never heard of. I then get chastised for not using Toplink or raw jdbc.

I was never asking that Hibernate translate a NULL in the db to something else. I will have to manually edit the generated DDL to remove the create table syntax for a view I have to another db, and I will add in defaults manually as well.

FYI, auto unboxing will throw a NPE anytime it tries to convert a NULL to a primative.

You should definitely look into UserTypes, even allows you to use default values.

Well you still can't have hibernate generate default values in your DDL. But I suppose if your DBAs are already bitching about it you already have the schema and won't run schemaexport daily, so manually modifying/writing the DDL should not be that a big problem.

If you really need it you can still modify SchemaExport - thats why it is called open source.

I would modify the code, but because the team would not want to accept the code back into the project, it would be a one off, which I doubt would be compatible with Hibernate 3.