Question

I’m working with an old database used by other applications, so i can’t modify its structure.
Sometimes i have nullable columns that i want to map as a non nullable type.
For instance I have a nullable EndValidity column on database which i want to map on a non nullable DateTime, and, if null, it should be DateTime.MaxValue, or as a more simple example, a nullable bit column that must be false if null.

I’m thinking about writing a custom user type for it (with parameters if possible), or is it there something included in nHibernate for it?

If the only solution is to write a custom usertype, for the boolean case, can I override fluentnhibernate conventions to always apply that usertype for booleans?

Answer 1

It probably depends on how you want your poco class you act.
Firstly if you load a null value do you want the null value to be re-saved or do you want any session commit/flush to update the record with the new default for the null field.
If you want to keep the null value in the DB how would you detect from your poco object with just a boolean which value to save IE booleans have only true and false options / values but your bit class has the options / values of null, 0 and 1?

If say: you want to have your nullable bits as a boolean and not a nullable boolean dataype in your poco class and have the class update the db to remove all the nulls then one solution which is pretty quick without diving into custom types is to have the two properties one nullable and protected or internal and one property in an interface ( without any mapping ) with basic logic – for reasons of dependancy injects all poco classes would ideally have an interface or two:
EG

internal virtual bool? isActive {get;set;}
public bool MyInterface.IsActive 
{
    get{ return isActive ?? false; }
    set{ isActive == value ?? false; };
}

This way your logic is contained in code so if the rules get more complex/complicated or one nullable bit has a default of false but another has a default of true ( because of some insane developer from last century ) you can more easily control the transformations.
It will require you working with interfaces instead of the real poco classes, but again this isn’t a bad thing, it just depends on your development model.