We talk about where to get NHibernate, a quick overview of starting an NH app, the state of NHForge, tooling and commercial support, the NHibernate ecosystem, and we compare the new EF “unicorn” features to features in NHibernate.

So, go listen now.

Thank you Scott, Fabio, and the guys at Pwop! I think the show turned out great, despite my nerves.

Oh, yeah. Frist!!!!!1!!!!one!!

It is an error to use a section registered as allowDefinition=’MachineToApplication’ beyond application level

It’s mysterious because I didn’t change my .configs. Double-clicking on the error took me to the <authentication> section of the web.config at the root of my app. It’s legal to define it there. Strange.

After trying a few different things, I started commenting out larger and larger chunks of my config, until it looked like this:

<configuration><!-- ... --></configuration>

Clearly, the error message was wrong.

As it turns out, this was my first time to build the app after using VS 2010’s Publish feature to throw it up on a server for a demo & user testing. Publishing packages up the website under .\obj\Release\Package, and it doesn’t clean up after itself. The next time I built my application, the compiler barked because I had a web.config hidden a few layers deep under .\obj with an <authentication> element.

I discovered the issue when I compiled my app at the command line and saw the full path on the error message. So, kill the .\obj folder after each publish, and you’ll never have this trouble.

Well, Simon Duduica is porting this over to .NET and NHibernate, and he’s making some AMAZING progress. On June 28th, he shared this news with us on the NH Contrib development group:

Hi everybody,

I have news regarding Envers.NET. I’ve commited a version that works in basic tests for CUD operations, with entities that have relationships between them, also with entities that are not audited. To make things work I had to make two small modifications of NHibernate, both modifications were tested running all NHibernate unit tests and they all passed. I already sent the first modification to Fabio and the second I will send this evening. I would like to thank Tuna for helping me out with good advices when I was stuck

So, on to the topic of this post. For NHibernate 3.0 Cookbook, I’ve included a section that explains how to use NHibernate to generate audit triggers. Originally, I had planned to use the code from my previous blog post on the topic, but I didn’t like its structure. I also didn’t want to include all that plumbing code in the printed book. Instead, I’ve rewritten and contributed the “framework” code to uNHAddIns. The “how-to use it” is explained in the book, so I won’t explain it here.

Today, I was writing an integration test for this contribution, and thought the idea was worth sharing. I have a simple Cat class:

When I do anything to this cat, in addition to the normal INSERT, UPDATE, or DELETE, a database trigger records that action in a table called CatAudit:

I wanted an easy way to investigate the contents of this table to prove that my audit triggers worked. Here’s what I came up with, along with help from Jose Romaniello (@jfroma). First, I created a class to match this table:

Next, I mapped it, made it readonly and excluded it from hbm2ddl with this mapping:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
				   assembly="uNhAddIns.Test"
				   namespace="uNhAddIns.Test.Audit.TriggerGenerator">
  <typedef class="NHibernate.Type.EnumStringType`1[[uNhAddIns.Audit.TriggerGenerator.TriggerActions, uNhAddIns]], NHibernate"
           name="triggerActions" />
  <class name="CatAudit"
         mutable="false"
         schema-action="none">
    <composite-id>
      <key-property name="Id" />
      <key-property name="AuditUser" />
      <key-property name="AuditTimestamp" />
    </composite-id>
    <property name="Color"/>
    <property name="AuditOperation" type="triggerActions" />
  </class>

</hibernate-mapping>

I made it readonly by setting mutable="false" and excluded it from hbm2ddl with schema-action="none". That’s it!

By the way, the <typedef> along with type="triggerActions" just tells NHibernate I’ve stored my TriggerActions enum values as strings, not numbers.

NHibernate 2 Beginner’s Guide by Aaron Cure is the 3rd published book about NHibernate. Each example in this book is presented in both C# and VB.NET, and some knowledge of these languages, as well as some basic understanding of ASP.NET WebForms is assumed.

Overall, for OR/M beginners and Entity Framework refugees, it provides a good foundation of NHibernate knowledge. The examples are simple enough to understand, and can easily be applied to real-world scenarios. There are, however, a few points of concern, such as the database-first approach, and the prescription of code generation.

Here’s a quick summary of what’s covered in each chapter:

As you might expect, chapter 1 gives a general overview of NHibernate, along with some code listings.

Chapter 2 sets up the database and table structure for the example model.

In chapter 3, the author takes us in to the world of POCO model design. He shows us NHibernate data types and their corresponding .NET data types, as well as setting up a collection for a one-to-many relationship.

In chapter 4, we begin the mapping process. After just a few pages, we have a completed NHibernate xml mapping. The chapter ends with a nice, quick example of a Fluent NHibernate code mapping. Chapter 4 is available for preview on the Packt Website.

In chapter 5, we start to get in to true NHibernate territory. The author shows us how to build a session factory, open a session, and then explains the proper use of transactions (Yes!). I would have preferred an example of session-per-request over the session provider singleton. Folks, save a kitten. Don’t use singletons.

Chapter 6 shows off all the log4net goodness baked in to NHibernate.

Chapter 7 explains the ins and outs of NHibernate configuration, with code and xml examples.

Chapter 8 shows us an example Data Access Object and how to build some Criteria queries with projections, paging, and sorting, It’s good stuff for beginners, but it doesn’t cover HQL.

In Chapter 9, the author shows us how to use NHibernate with ASP.NET WebForms data binding. No beginner’s book would be complete without showing the Microsoft way.

Chapter 10 deals with ASP.NET security and authorization, including a membership provider based on NHibernate.

Chapter 11 shows off several code generation tools. While this is the logical destination for anyone using a database-first approach, with a model-first approach, its unnecessary for all but the largest projects.

Disclosure: In exchange for non-monetary compensation, I worked as one of two technical reviewers on this book, and I am currently writing NHibernate 3 Cookbook, to be published by Packt later this year.

Simon Duduica of Bucharest, Romania and his team are porting Hibernate Envers to .NET / NHibernate.

Michele Minorello is working on NHibernate Search to add Loquacious configuration and Linq2Lucene.

I have a book deal with Packt Publishing. NHibernate 3.0 Cookbook will cover existing and new 3.0 features of NHibernate, as a series of short, easy to follow recipes that can be combined to build great NHibernate applications. In addition to NHibernate 3, the book also covers NHContrib projects, some ideas from uNHAddIns, fluent & auto-mapping with Fluent NHibernate, and ConfORM.

I’d like to send a HUGE thank you to my technical reviewers, including Fabio Maulo, Jose Romaniello, and Tuna Toksoz.

When creating lambdas (including LINQ expressions) inside a for each loop, don’t use the iterator variable in your lambda. Let me explain with some code:

foreach (Type controllerType in controllerTypes)
{
     kernel.Bind(controllerType).ToSelf().InRequestScope();
     kernel.Bind<IController>().ToMethod(ctx => ctx.kernel.Get(controllerType)).Named(GetName(controllerType));
}

Why am I using a method to get the controller? It just so happens that my AccountController is also a domain event handler for my AccountNameAlreadyUsed event. This goes back to Ayende’s tip in my domain events post: To get a message back to the UI, fire a new event and have the UI listen for it. In this case, I need the UI to complain when the account name they selected is already being used.

In case your mind has wandered to the dark side, throwing exceptions is not an acceptable way of passing messages in an application.

Now, why the odd mappings? Let’s say I bind IController and IHandle<AccountNameAlreadyUsed> to AccountController in the request scope. It doesn’t quite work like you would first expect. You will have one instance of AccountController returned for IController and a separate instance for IHandle<AccountNameAlreadyUsed>.

Instead, I’m saying that for each request for an IController, go get an AccountController, essentially delegating the request to the ToSelf() binding. I have a similar ToMethod() lambda binding for IHandle<AccountNameAlreadyUsed>. Since both interface bindings are fulfilled by the ToSelf binding, only one instance of AccountController is created for the request, instead of two.

So, this explains why I need the lambda in the first place. Why didn’t the code above work?

As it turns out, there was some funny business going on underneath the covers between the foreach iterator and the lambda. Here’s the symptom: No matter which “instance” of the lambda was being referenced, inside the lambda, the iterator variable (controllerType) was always the first value that was iterated. No matter which controller I requested, I always got an instance of AccountController, since it happens to be first alphabetically.

Once you realize what’s going on, the fix is simple. Create another variable and use it inside the lambda instead. So, instead of the code above, we get this:

foreach (Type controllerType in controllerTypes)
{
     var controllerType2 = controllerType;
     kernel.Bind(controllerType).ToSelf().InRequestScope();
     kernel.Bind<IController>().ToMethod(ctx => ctx.kernel.Get(controllerType2)).Named(GetName(controllerType));
}

If, instead of a lambda, we had a LINQ expression, the compiler would generate a warning about this issue – at least in VB.NET. If I hadn’t already seen that warning from LINQ expressions, I would probably still be bug hunting.

Jason

• Fabio has been busy on some really amazing mapping magic.
• Aaron Cure’s NHibernate 2.x Beginners Guide from Packt Publishing will be out in May.
• I’m making progress on Project Nenverse. The concept is similar to Hibernate’s Envers. I’m not ready to announce it to the world just yet, but you want to look over the code or even contribute, it’s out there.
• In an effort to avoid meta-blogging at all cost, I won’t mention the cool new stuff over on the right, or the new text up above.

That’s it for now.

The ALT.NET crowd is almost exclusively C#, except where they’ve moved beyond it.  If I’m going to participate, it’s past time for me to become fluent. Until at least April, I won’t write a single line of VB.NET outside of work.

The Problem

My previous examples have used system_user as the source of user information in the audit log, which required you to impersonate users down to the database level, that is to open the connection in the context of the application user, not some shared generic account. There are several reasons why this is not a good idea:

1. You either don’t have per-user credentials appropriate to create SQL server accounts (typical in public-facing web applications), or are unable to do so for various reasons ranging from security concerns to account management workload.
2. When each user authenticates with their own credentials, this effectively disables connection pooling. Especially in high-volume web scenarios, this will kill performance and put a strain on server resources.
3. I believe the loss of connection pooling will also burn through your license pool with per-user licensed SQL servers. I may be mistaken on this point, as I haven’t worked with a per-user licensed SQL server for the better part of a decade.
4. If you are unwilling to use SQL server authentication, you will most likely have to set up Kerberos constrained delegation so that your database server trusts your web server to authenticate users. This is a royal PITA to implement.

The Trouble With Triggers

As far as input inside a trigger, you only have access to the data being manipulated, system functions, and very little else. You can’t use SELECT statements in triggers either, at least not against normal tables and views.

SQL Context Info

Starting with MS SQL Server 2000, you can associate up to 128 bytes of data with the current connection using the SET CONTEXT_INFO command. Starting with SQL 2005, you can use the CONTEXT_INFO function to retrieve this data. This data is available everywhere, including triggers.

If you use connection pooling (and you probably are), this data is not reset when the connection is reused.

To set your context info data, use the SET CONTEXT_INFO command like so:

DECLARE @Ctx varbinary(128)
SELECT @Ctx = CONVERT(varbinary(128), 'My context data goes here.')
SET CONTEXT_INFO @Ctx

SET CONTEXT_INFO can only be used with variables and constants, meaning you can’t CONVERT data types or concatenate strings or any other calculation in the same command.

To retrieve the context data, use the CONTEXT_INFO function:

DECLARE @CtxData varchar(128)
SELECT @CtxData = CONVERT(VarChar(128), CONTEXT_INFO())
PRINT @CtxData

This will output ‘My context data goes here.\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’ etc. Note – The \0 is ASCII character 0 (NULL). Why? We’re converting the string to fixed-length binary and then converting it back.

Know Your Roots

There was a time when programmers weren’t protected from the fact that strings are just chunks of memory. Just like programmers in the old days, you have two options: Pascal strings or C strings. You can stuff a length byte at the beginning of your context as in Pascal, or you can search for the null termination of your string as in the C language.

Also, because nchar and nvarchar are UNICODE UCS-2 strings, they use two bytes (of your 128 maximum) per character. char and varchar only use one byte per character, but the character set is limited. It’s a trade-off.

How does this help me?

We can use context info data to get information from our application in to our audit triggers. For example, we can get the current user name from our application or evem some identifying information about the location in our application, such as the name of the controller and action that triggered the event. Just be conscious of the 128 byte limitation. It’s probably better to store an id for more information such as the id of the user account, or an id that references some lookup table with application locations.

The Code, Sir.

We will override the GetConntion() method of DriverConnectionProvider so that every NHibernate connection will have the current username stored in the context.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NHibernate.Connection;
using System.Data;

namespace NHibernate.Connection
{
    public class ContextDriverConnectionProvider : DriverConnectionProvider
    {

        public override System.Data.IDbConnection GetConnection()
        {
            var conn = base.GetConnection();
            SetContext(conn);
            return conn;
        }

        private const string CONTEXT_SQL = "declare @Length tinyint\ndeclare @Ctx varbinary(128)\nselect @Length = len(@username)\nselect @Ctx = convert(binary(1), @Length) + convert(varbinary(127), @username)\nset context_info @Ctx";

        protected virtual void SetContext(IDbConnection conn)
        {
            IDbCommand cmd = conn.CreateCommand();
            IDbDataParameter param = cmd.CreateParameter();
            cmd.CommandType = CommandType.Text;
            cmd.CommandText = CONTEXT_SQL;

            param.ParameterName = "@username";
            param.DbType = DbType.AnsiString;
            param.Size = 127;
            param.Value = System.Environmnt.UserName;
            cmd.Parameters.Add(param);

            cmd.ExecuteNonQuery();
        }

    }
}

This will run the following SQL code when NHibernate opens a SQL connection. Note that @username is a variable defined as a parameter on our IDbCommand. Also, I chose to use Pascal strings with the length stored in the first byte.

declare @Length tinyint
declare @Ctx varbinary(128)
select @Length = len(@username)
select @Ctx = convert(binary(1), @Length) + convert(varbinary(127), @username)
set context_info @Ctx

We’ll alter our trigger code to get the username from the context instead of system_user.

set nocount on
declare @Username varchar(127)
declare @Length tinyint
declare @Ctx varbinary(128)
select @Ctx = CONTEXT_INFO()
select @Length = convert(tinyint, substring(@Ctx, 1, 1))
select @Username = convert(varchar(127), substring(@Ctx, 2, 1 + @Length))
if (@Username is null) select @Username = SYSTEM_USER

Security Implications

I am not a security expert. I am certainly not a SQL security expert. However, I believe this method is secure for most scenarios. In my opinion, this is at least as secure as auditing through NHibernate interceptors and events.

Here’s a few ways to circumvent the system, and how you can prevent that from happening:

• Manipulate the audit logs directly. Obviously, in any audit scenario, you should set permission on your audit tables to make them select and insert only.
• Alter the context_info data directly. A user overwrites their own context_info with that of another user, effectively blaming their actions on someone else. This can be done through a SQL injection attack some other security breach. If you go on vacation with the front door open, don’t be surprised when your house is robbed.
• Fail to set context_info. Again, this requires some other security breach. You may also change your trigger code to ROLLBACK TRANSACTION and RAISERROR when context_info is not set. This will force a rollback of the transaction (or in the case of no explicit transaction, the SQL statement that caused the trigger), abort the remainder of the SQL batch, and report an error. The approach requires everyone, including your DBA, to set an appropriate context_info before altering any audited data.

This is certainly my worst blog post this year, but don’t worry. I can do worse.

- Jason