I have been talking a lot lately about the technical aspects of working with NH Prof (and there are more posts scheduled), but not really talking about the new features at all. I firmly believe in the lynched-by-the-users model, and working for so long without having new features is an anathema to me.

I am going to try to leak them to the blog as they go fully online (with screenshotable UI), although I do mean to keep several surprises in my sleeve, and in my backpack, too, come to think about it, I need space for some of them ;-) ).

Anyway, I don’t think that this screen shot requires any additional explanations:

Unlike my previous posts about NH Prof’s new features, this is not currently available to download. Currently we are planning to sync up everything and show you what we got by the end of the week, so this is truly just a sneak peak right now.

The really amazing part of this feature? I did it, all on my own. The reason that I am surprised is that this feature actually have UI in it. And my facilities in UI manipulation are decidedly lacking. Nevertheless, this is all my work. The UI team didn’t have to get involved. I mentioned before how impressed I am by the work Christopher and Rob did on NH Prof. What I didn’t think got mentioned was the UI architecture that they built. Working separately, both me and Christopher & Rob has reached the same type of general architecture, based on concepts and features.

This report is a new feature based on an existing concept. The work to make that happen was already done, when the concept was introduced. Creating a new feature is a piece of cake now, and doesn’t require any special knowledge or any UI talent.

I am loving it.

Oh, and just to give you an idea about the time frame, I started coding the UI about 45 minutes ago, because I sat down to ensure that NH Prof was ready to show for my NHibernate workshops. I got sidetracked a bit and wired the feature into the UI. It is actually a bit more impressive, because the 45 minutes time also include the time to write the blog post :-)

At last, we have a cool UI for this feature.

It starts here:

And then moves to this window:

Yes, I know, it is not earth shattering UI, for sure, but it is one hell of a cool way to inspect even deeper into what NHibernate is doing.

Yes, I am aware that I said that I would only have two more feature for NH Prof before releasing. But I am currently being held hostage by the new features fairy, and negotiations over a feature freeze seems to have gotten to a stand still. Beside, it is a neat feature.

The actual feature is quite simple. Let us say that we have the following model:

Notice that this is a very common case of bidirectional association, and this is mapped to the following table model:

Notice that while on the object model this is a bidirectional association and is maintained by two different places, it is maintained on a single place in the database.

This is a a very common case, and quite a few people get it wrong. By default, NHibernate has to assume that it must update the column on both sides, so creating a new post and adding it to the Blog’s Posts collection will result in two statements being written to the database:

   1: INSERT INTO Posts(Title,

   2:                   Text,

   3:                   PostedAt,

   4:                   BlogId,

   5:                   UserId)

   6: VALUES     ('vam' /* @p0 */,

   7:             'abc' /* @p1 */,

   8:             '1/17/2009 5:28:52 PM' /* @p2 */,

   9:             1 /* @p3 */,

  10:             1 /* @p4 */);

  11: select SCOPE_IDENTITY ( )

  12:  

  13: UPDATE Posts

  14: SET    BlogId = 1 /* @p0_0 */

  15: WHERE  Id = 22 /* @p1_0 */

As you can see, we are actually setting the BlogId to the same value, twice.

Now, there is a very easy fix for this issue, all you have to do is to tell NHibernate on the Blog’s Posts mapping that this is a collection where the responsibility for actually updating the column value is on the other side. This is also something that I tend to check in code reviews quite often. The fix is literally just specifying inverse=’true’ on the <many-to-one> association.

And now NH Prof will detect and warn about such cased:

Beautiful!

This is also the first case in which I am starting to do much more in depth analysis of what is actually going on with NHibernate. I planned to do this sort of thing after the v1.0 release, but as I said, I am held hostage by the new features fairy, and this is my negotiation technique :-)

Now that is what I call a hard to build feature. Well, it wasn’t hard, it was just tedious to do. This feature required me to modify 66 files(!). Since I pride myself on the mostly frictionless nature of NH Prof, that was annoying. The real issue was that this required that I would change all layers in the application to start tracking the URL from which the event was generated. Since we have a rigid separation between the different parts, and since we track so many things, it was mainly an annoying task to go and add a URL to all of them.

Anyway, you probably don’t really care about my trouble in implementing this feature, let us talk about the actual feature.

We can track which URL opened a session:

And even which URL is responsible for each session:

This is the first of the last three features that I have left. I’ll discuss the other two shortly.

Here is another nice one:

And the disclaimer is that this works on NHibernate from r3981 or higher.

I did some work on NHibernate's System.Transactions support recently, and that was one of the side results.

Okay, I said it is not there yet, but I got annoyed by the lack of this feature, and I really had to make this work.

That one was a pretty tough one. It required me to make some minor modifications to NHiberante, as a result, this feature works with NHbierante r3976 or up only. What this means is that if you want to use this feature, you have to get it from the trunk.

This is the only feature in NH Prof that requires the trunk.

In this feature, we can see that we detect a cached query, and are able to display it properly.:

I am not sure how I should treat this for the purpose of analysis. Should this be grouped with the actual query? Should this be a separate entry?

Anyway, just for kicks, here is the test for the feature:

[TestFixture]
public class CachingTestFixture : IntegrationTestBase
{
    [Test]
    public void CanDetectCachedQueries()
    {
        ExecuteScenarioInDifferentAppDomain<UsingCacheQueries>();

    	var array = observer.Model.Sessions[2].Statements.OfType<StatementModel>()
    		.ToArray();
		Assert.AreEqual(@"Cached query: 
SELECT this_.Id             as Id7_0_,
   this_.Title          as Title7_0_,
   this_.Subtitle       as Subtitle7_0_,
   this_.AllowsComments as AllowsCo4_7_0_,
   this_.CreatedAt      as CreatedAt7_0_
FROM   Blogs this_
WHERE  this_.Title = 'The lazy blog' /* @p0 */
   and this_.Id = 1 /* @p1 */
", array[0].Text);
		Assert.AreEqual(@"Cached query: 
select blog0_.Id             as Id7_,
   blog0_.Title          as Title7_,
   blog0_.Subtitle       as Subtitle7_,
   blog0_.AllowsComments as AllowsCo4_7_,
   blog0_.CreatedAt      as CreatedAt7_
from   Blogs blog0_
where  ( blog0_.Title = 'The lazy blog' /* @p0 */ )
   and ( blog0_.Id = 1 /* @p1 */ )
", array[2].Text);
    }
}

As an aside, do you think that posting the tests is good? Should I just do the screen shots?

I keep adding new features and fixing strange bugs in NH Prof. Most of those aren't really interesting things.

Does anyone really care about sort order in a particular query? Those are things that are important for the overall UX, but they are not things that I can honestly call them features.

This thing, however, is a full blown feature. Even if it takes just a tiny bit of screen real estate.

And integrating it into the analysis section of NH Prof as well:

And in the views by method report:

And something that is important to remember, the moment that I have a piece of information, I can start making use of it in alerts and rules. I haven't decided yet if I want to do so for the v1.0 release, but I have a feeling that this is going to be a very useful base for additional features.

One of the things that I am doing with NH Prof is not only giving you visibility into what NHibernate is doing, but also trying to automate my own experience in analyzing best practices and problematic usages of NHibernate.

NH Prof will detect usage patterns and warn against bad practices and suggest how to deal with them. The first one that I implemented was detecting Select N+1, and the feedback from the beta group was "Wow! I didn't even know that we had this problem, but casual use with the profiler immediately showed it."

Here is the newest feature, detecting & warning about unbounded result sets:

And the actual warning:

That was actually a hard to implement feature, since this is not something that NHibernate just give out. Nevertheless, by trawling through the codebase long enough, I was able to figure out how to do this.

As an aside, one of the requested features for NH Prof was to be able to get DB level stats. I am not going to do this for v1.0, but I now have a pretty firm idea about how to implement this. We will have to see how many people request this information.