James Kovacs' Weblog

A few weeks ago I was merrily working away on an application that uses NHibernate to query data from an Oracle database. I didn’t feel like installing a local Oracle instance as typically I do more work against SQL Server. So I develop locally against a SQL Server database and switch to Oracle by changing a few NHibernate configuration settings. Very nice. I deploy the application into the test environment and it fails with:

ORA-12571: TNS:packet writer failure

Examining the stack trace, the error was happening in the guts of the Oracle driver. Looking up the documentation, this error typically indicates a faulty network cable or similar hardware cause. So I try another query. This time it works. I try my queries one at a time. Only one query is failing. What are the chances that the network cable only comes loose when executing a certain query? Not terribly likely, IMHO.

So I reproduced the error in a simple application and started pulling it apart. I’ll save you the blow-by-blow, but suffice it to say, the only difference between the working queries and broken query was the query parameters. (Also note that the identical code worked fine against SQL Server.) Working queries had integer parameters. The broken query had a string parameter. As soon as I realized this, I made an educated guess that it was a Unicode/ASCII conversion problem. I modified my mapping file to include the datatype in the property definition:

<property name=”InvoiceNumber” column=”invoice_num” type=”AnsiString” not-null=”true”/>

Now both Oracle and SQL Server were happy to execute the query. (N.B. Usually NHibernate can properly infer the datatype based on the property type on the class. So it is not required.)

Come on now, Oracle! Loose network cable??? Not “unable to convert Unicode to ASCII” or “unexpected datatype” or something vaguely useful. Loose network cable??? Hardware failure??? Oracle has a long way to go in improving their error messages. My database of choice is still SQL Server because, most of the time, it just works.

In a domain model, you will sometimes encounter immutable data – objects that can only be read from a database, but never modified. The question is how to test your persistence layer to ensure that you can read them. One way is to hard code values into your tests and assume that the appropriate rows are in the database. This is rather fragile as you are counting on your database being in a known good state. This also prevents you (or another developer) from getting latest from source control onto a clean developer workstation and being able to run the unit tests immediately. You must populate a test database with known good data first. Here’s a little trick you can play with NHibernate. Let’s say you have the following class:

namespace JamesKovacs.Examples.ImmutableData {
    public class Invoice {
        private readonly int m_Id = 0;
        private readonly string m_InvoiceNumber;
        private readonly decimal m_Amount;
        private readonly DateTime m_InvoiceDate;

        public Invoice() {
        }

        public Invoice(string invoiceNumber, decimal amount, DateTime invoiceDate) {
            m_Amount = amount;
            m_InvoiceDate = invoiceDate;
            m_InvoiceNumber = invoiceNumber;
        }

        public int Id {
            get { return m_Id; }
        }

        public string InvoiceNumber {
            get { return m_InvoiceNumber; }
        }

        public DateTime InvoiceDate {
            get { return m_InvoiceDate; }
        }

        public decimal Amount {
            get { return m_Amount; }
        }
    }
}

And its corresponding NHibernate mapping file:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   namespace="JamesKovacs.Examples.ImmutableData"
                   assembly="JamesKovacs.Examples.ImmutableData"
                   default-access="field.pascalcase-m-underscore">
  <class name="Invoice" mutable="false">
    <id name="Id">
      <generator class="native" />
    </id>
    <property name="InvoiceNumber"/>
    <property name="Amount"/>
    <property name="InvoiceDate"/>
  </class>
</hibernate-mapping>

Note that the Invoice is lookup data only. So it is declared as immutable in the mapping file (mutable=”false”). NHibernate will not permit INSERT, UPDATE, or DELETE operations against the entity. The question is how do we test this? We could circumvent NHibernate and directly insert test data into the table via ADO.NET. The downside is that you’re coupling your test data generation code to a particular database schema. If the database schema changes, you must not only update the NHibernate mapping, but you must also modify your SQL statements for creating test data. A definite violation of DRY (Don’t Repeat Yourself) Principle. Let’s see if there is a better way…

NHibernate can generate the database schema from mapping files using NHibernate.Tool.hbm2ddl.SchemaExport. The problem is that you can’t insert data into the Invoice table since the type is mapped as immutable. However, you can read the NHibernate configuration and mapping files and modify the mapping at runtime. This is done by cfg.GetClassMapping(typeof(Invoice)).IsMutable = true. We’re switching our immutable entity to a mutable one on the fly for the purposes of populating test data! Note that you have to modify the mapping before creating your SessionFactory.

using System;
using JamesKovacs.Examples.ImmutableData;
using MbUnit.Framework;
using NHibernate;
using NHibernate.Cfg;
using NHibernate.Tool.hbm2ddl;

namespace JamesKovacs.Examples.ImmutableData.Tests {
    [TestFixture]
    public class InvoiceRepositoryTests {
        private const string InvoiceNumber = "ABCD1234";
        // N.B. You should do this once before all your repository tests
        //      as creating a SessionFactory and executing DDL is time-consuming.
       [SetUp]
        public void Setup() {
            Configuration cfg = new Configuration().Configure();
            SchemaExport exporter = new SchemaExport(cfg);
            exporter.Execute(false, true, false, false);
            cfg.GetClassMapping(typeof(Invoice)).IsMutable = true;
            ISessionFactory sessionFactory = cfg.BuildSessionFactory();
            using(ISession session = sessionFactory.OpenSession()) {
                session.BeginTransaction();
                Invoice invoice = new Invoice(InvoiceNumber, 42m, DateTime.Today);
                session.Save(invoice);
                session.Transaction.Commit();
            }
        }

        [Test]
        public void CanRetrieveInvoice() {
            using(UnitOfWork.Start()) {
                IInvoiceRepository repo = new InvoiceRepository();
                Invoice invoice = repo.FindByInvoiceNumber(InvoiceNumber);
                Assert.IsNotNull(invoice);
                Assert.AreEqual(InvoiceNumber, invoice.InvoiceNumber);
            }
        }
    }
}

So we now have an elegant solution for populating immutable test data in a clean database without resorting to hand-coded SQL.

N.B. UnitOfWork.Start() sets up an NHibernate session that is used internally by the repositories. It is based on Oren Eini’s UnitOfWork implementation in Rhino Commons.