Geek Answers Handbook

NHibernate Mapping Sanity Checks

Currently, our new database design is changing rapidly, and I do not always have time to keep abreast of the latest changes. Therefore, I would like to create some basic integration tests , which mainly relate to sanity checks in my comparisons to the database.

Here are a few things I would like to accomplish in these tests:

  • Detecting columns that I did not define in my mapping but exist in the database
  • Detecting columns that I have mapped but DO NOT exist in the database
  • Detecting columns that I have mapped where the data types between the database and my business objects no longer jingle with each other.
  • Detecting column name changes between the database and my mapping

I found the following article by Ayende, but I just want to see what other people do to deal with such things. Basically, I am looking for simplified tests, which cover many of my comparisons, but do not require me to write separate queries for each business object in my comparisons.

+4
source share
2 answers

I am pleased with this test, which comes from the proposed Ayende:

[Test] public void PerformSanityCheck() { foreach (var s in NHHelper.Instance.GetConfig().ClassMappings) { Console.WriteLine(" *************** " + s.MappedClass.Name); NHHelper.Instance.CurrentSession.CreateQuery(string.Format("from {0} e", s.MappedClass.Name)) .SetFirstResult(0).SetMaxResults(50).List(); } }

I am using a simple old query since this version comes from a very old project and I have to be lazy to update QueryOver or Linq2NH or something else ... It's basically ping all matching objects configured and capturing some data to make sure that everything is all right. It does not matter if there is any field in the table, but not on the mapping, which can generate a problem in constancy if it is not null. I know that Fabio Maulo has something more accurate . As a personal consideration, if you are thinking of an improvement, I would try to implement such a strategy: since the association is being viewed by the API, look for some explicit / implicit table declaration on the map and ping it using the database using the standard helperclasses scheme, which you have NH inside (they ultimately use the ADO.NET schema classes, but they isolate all the configuration elements that we have already done in NH itself). With a little naming strategy, we can get one after another a checklist of table fields. Another improvement can be made if you refuse to search for a candidate by applying Levensthein Distance for all available names and selecting one of them if some threshold requirements are met. This, of course, is useless in the first class scenarios when the database schema is generated by NH itself.

+3
source

More articles:


All Articles