Messy database: NHibernate as the maid...
time to read 4 min | 624 words

If you ever had to work with someone else's database (I assume that yours are perfect), you know that not all databases are nice and clean. In fact, some of them fail to do even simple things, like foreign keys. In some cases, FK is not even possible (think a view over a main frame table that you don't control).

In such cases, almost invariablely, the database slightly corrupts itself. Sometimes it is a programmer error, sometime a failed set of commands without transactions, etc. The end result is that you get an id to another table, but no row that match this id. To say that it is hard to deal with this kind of scenario is an understatement. Even if we are dealing with a nullable FK (which is not always the case), if it has a value, but no matching record, this is a big issue.

Most often, this lead to an attempt to "clean up the data", but this usually lead to finding even more issues, and in many cases there is a big fear that this will damage business critical data. The developers are then left to fend themselves against the unruly database (and the damaged relational model is weaping at the corner).

In NHibernate 1.2, a new attribute was introduced to help solve this issue, this is not-found="ignore", which instruct NHibernate to treat non existing FK not as errors (as is the default), but as nulls. Here is a simple example:

<many-to-one name="Parent" column="ParentId"

                      lazy="proxy" not-found="ignore"

                      class="Item"/>

The nice thing about this feature is that if you save this object into the database, NHibernate will update the column to NULL, helping to restore the database to a sane state.

Tweet Share Share 0 comments
Tags: