We have recently update to NHibernate 3 in one of our projects. While testing I was suddenly seeing some weird UPDATE statements in NHprof.

It seemed like the NHibernate IsDirty detection had changed.

After some digging it turned out that our mapping files (made in FluentNhibernate) actually contained some minor errors when compared to the DB schema. Minor errors like value typed properties not being nullable when the ClassMap said it should be.

Debugging of NHibernate projects

I found that inserting the following into the classmaps made debugging a lot easier:

DynamicUpdate();

Now only the properties that are Dirty (according to NHibernate) are used in the SQL UPDATE statement. Here are the description from NHibernate docs:

• dynamic-update (optional, defaults to false): Specifies that UPDATE SQL should be generated at runtime and contain only those columns whose values have changed.
• dynamic-insert: (optional, defaults to false): Specifies that INSERT SQL should be generated at runtime and contain only the columns whose values are not null.

That led me directly to the property in the mapping files that had errors in it, and I could easily fix it.

Conclusion

So, in our case, it wasn’t really the NHibernate dirty detection that changed, NHibernate 3 is just not as fault tolerant, than that of NH2. So the upgrade made us discover some errors that should be corrected.

As such, this is a good thing, but it would have been nicer if NH2 had made us aware of these errors in the first place.

But hey, better late than never

Using the “Stack Trace” in NHprof I identified a call being made to GetHashCode() of the class (MyClass) holding the composite id. MyClass looked like this:

public class MyClass
{
    public virtual Key1Class Key1 { get; set; }
    public virtual Key2Class Key2 { get; set; }

    /*
     * Other virtual properties
     * ...
     */

    public override int GetHashCode()
    {
        unchecked
        {
            return ((Key1 != null ? Key1.GetHashCode() : 0) * 397) ^ (Key2 != null ? Key2.GetHashCode() : 0);
        }
    }
}

Note that Key1 and Key2 are both references, and please take a closer look at the GetHashCode method.

The problem

The problem I was facing… NHibernate called the GetHashCode() of MyClass when doing the query. And the call to MyClass‘s GetHashCode method subsequentily called GetHashCode() of both the Key1 and Key2 classes.

Key1 and Key2 were loaded as proxies and hence a call to something else than theirs Id resulted in a select being fired.

The solution

The solution was to rewrite the GetHashCode method to this:

public override int GetHashCode()
{
    unchecked
    {
        return ((Key1 != null ? Key1.Id : 0) * 397) ^ (Key2 != null ? Key2.Id : 0);
    }
}

Note that both Id’s of KeyClass1 and KeyClass2 are integers.

Now a call to MyClass GetHashCode does not result in individual SELECT statements being fired, even though the Keys area lazy loaded.

Reference:
http://west-wind.com/weblog/posts/132081.aspx

I have been using NHibernate for some time now, and I am very satisfied with the functionality it provides. However, I do really not like “magic strings” as these makes the code resistent to refactoring.

NHibernate makes use of “magic strings” when doing a query using HQL or the Criteria API. I tend to use the Criteria API as this, opposed to HQL, limits the logic encompassed in “magic strings”.

As I mostly use the Criteria API, I thought, why not do something about it  So I did. Very quickly a Fluent Criteria interface was implemented. Here is how it is used:

var email = "email@email.com";
var customerType = CustomerType.Default;

var result = nhSession.Criteria<Customer>()
             .Add.Equals(x => x.Email, email)
             .Add.Equals(x => x.Type, customerType)
             .Order.Desc(x => x.Created)
             .NHCriteria
                 .SetMaxResults(1)
                 .UniqueResult<Customer>();

In this line we call the extension method Criteria with Customer as a generic argument:

var result = nhSession.Criteria<Customer>()

By doing so we of the alternate Fluent Criteria API I have implemented. Currently it is only some of the Restrictions and Order classes that have been implemented, but you are free to use these classes and extend them as you wish.

By calling the NHCriteria property, you get the normal NHibernate criteria API, so here you can set the cache options, max results, etc.

Download the source code here http://ovesen.codeplex.com/wikipage?title=NHibernateFluentCriteria&referringTitle=Home

Happy New Year btw

The configuration sis done in Fluent NHibernate.

http://codebetter.com/blogs/kyle.baley/archive/2008/12/24/many-to-many-relationships-with-data-attached-in-nhibernate.aspx

http://ayende.com/Blog/archive/2006/12/02/NHibernateCascadesTheDifferentBetweenAllAlldeleteorphansAndSaveupdate.aspx

Here is the basics:

Here is what each cascade option means:

• none – do not do any cascades, let the users handles them by themselves.
• save-update – when the object is saved/updated, check the assoications and save/update any object that require it (including save/update the assoications in many-to-many scenario).
• delete – when the object is deleted, delete all the objects in the assoication.
• delete-orphans – when the object is deleted, delete all the objects in the assoication. In addition to that, when an object is removed from the assoication and not assoicated with another object (orphaned), also delete it.
• all – when an object is save/update/delete, check the assoications and save/update/delete all the objects found.
• all-delete-orhpans – when an object is save/update/delete, check the assoications and save/update/delete all the objects found. In additional to that, when an object is removed from the assoication and not assoicated with another object (orphaned), also delete it.

Update 18-11-2008, well it turs out there infect is a NHibernate 2.0documentation here:

http://nhforge.org/doc/nh/en/index.html

A very good place to start is here:

http://www.hibernate.org/hib_docs/v3/reference/en-US/html/

Properties

Chapter 5 explains setting up properties in the mapping file, tags and attributes.

http://www.hibernate.org/hib_docs/v3/reference/en-US/html/mapping.html

Collections

Chapter 6 is about collections and lists

http://www.hibernate.org/hib_docs/v3/reference/en-US/html/collections.html

Many-to-many relations

Handling many-to-many relations can be difficult, especially when it comes to cascading and data integrity. This blog post explains one way of handling it.

http://codebetter.com/blogs/peter.van.ooijen/archive/2008/05/29/nhibernate-many-to-many-collections-or-mapping-is-not-one-table-one-class.aspx