How is everyone else handling this?

I have a new entitiy I want to insert. In my mapping file, I've set the property/column to be not-null. For example:

<property name="SupplierContactEnabled" type="Boolean" >
<column name="SupplierContactEnabled" length="1" sql-type="tinyint" not-null="true" />
</property>

In the db, this has a default of 0 (false).

I have dynamic-insert set to true, but that really only applies to the SQL that gets generated. NHibernate objects when trying to save...that the not-null property has a null value.

The easy fix is to just omit the not-null attribute. Is there a better way?

Thanks in advance...
E

i'm not sure i'm understanding your question, but if your db has a default value of 0 (false) then your class constructor should set the value to false as well:



in this instance, even with dynamic SQL, the proper SQL would be generated and data integrity would be maintained. imho, a nullable bool is a misnomer. bool is either true or false, not true, false or null.

-devon

Thanks for the reply, Devon.

I was afraid that might be the solution. It's not that bad putting it into the constructor...we'd have to hack it into our Codesmith templates...but can I follow up with another question?

The situation below occurs in literally thousands of places in our database for different datatypes. If we're not handling any specific exceptions on trying to commit, would it be *bad* to remove the not-null attribute? We'd still get the SQL exception bubbled up to us...

Thanks!

well this is just my opinion, but i don't think your idea is *bad* if it saves you time in development. the caveat is that it should not increase time in support. thoughts if you proceed down this route:

1) you should probably use Nullables.NullableBoolean. you will be able to create robust error checking.

2) try and include some logic in your code that handles the error properly. i don't think you want SQL exceptions bubbling up to the UI.

just some quick thoughts.

-devon