Wednesday, August 26, 2009

NHibernate Schema Export Frustrations!

NHibernate makes schema creation quick and easy, but one situation I found annoying was that calling new SchemaExport().Execute() wouldn't drop the existing schema first. I found myself manually deleting the tables in the database in the correct sequence every time I wanted to blow away the schema and rebuild it.


Through some Googling, I discovered that if you split the SchemaExport into multiple calls, you no longer receive the issue.



It seems as though the Drop method doesn't have an issue on a fresh database, yet drops the database elements of they already exist.

Playtime with NHibernate and Spelling mistakes :(

So I have finally decided I have some time to take a look at NHibernate. My curiosity for the tool has as of recent, become quite large. Two of the team members where I am currently working keep ranting and raving about how "If we were using NHibernate...", "NHibernate would be able to do this easier..." and so on.

Nearing the end of one of our projects, I am finding myself having some free time, yet nothing to fill that time with. What a great opportunity to familiarize myself with a new tool, even possibly prepare myself to implement it in the coming project.

After taking a first stab at the tool, I can say that the concepts are pretty simple to grasp. Once you finally get it working, you can see a lot of the benefits that it can bring to a project. Speed and time are definitely saved in having to write schema scripts and stored procedures. The only drawback that I can see with the tool, is the learning curve of setting up the XML mapping documents and configuring the tool correctly.

It was probably two days that I had been looking at NHibernate and getting things initally set up wasn't too difficult. As soon as I attempted to create a DB schema and insert one-to-many relationships, all of my motivation flew out the window. I ran into the issue of my child elements not being linked to my parent elements in the database. The parent ids were not getting stored and as a result they were stored as null. I had 3 other developers, all who of which had one-to-many relationships working with the tool in the past, look at what I had set up. We were all mind boggled. It was only then that one of the developers said, "Get rid of all the table="something" and column="something" so we can simplify the issue. After doing so, the ids for the parent-child relationships were being set. Further investigation lead to the discovery that one of the table names didn't match what was defined. This lead to the null entry in the child table for the parent id. Now the problem is solved, but the issue remains that although the tool is very powerful and makes your life easier, it can also just as quickly drain you will to live. Be careful with your spelling, and remember to bring a problem to its simplest form.