Denormalize data using NHibernate’s Property Accessors

One of the most useful things you can do when setting up an NHibernate environment is to sort out of the XSDs so that Intellisense works in Visual Studio.  Note that the documentation is rather out of date.  Most people are now using the 2.2 schema, not the 2.0 schema, and the Visual Studio directory in 2008 is C:Program FilesMicrosoft Visual Studio 9.0XmlSchemas.  Especially notice the “.0”, which is new.

Sorting this out not only allows you to more quickly see errors in your HBM files (a major benefit in itself) but also enables one of my favourite learning approaches: Intellisense exploration.  This, in combination with reading the documentation, can give you a fairly broad picture of the functionality.  In particular, it provided me with an answer to a question that had been bugging me for a while: how to denormalize data with NHibernate. NHibernate’s support for dealing with database structures that do not map directly to your domain is one of its strongest features, but nearly all examples on the Internet deal with the simple case of mapping directly to a closely related data structure.  This is hardly NHibernate’s fault: Microsoft examples suffer from exactly the same problem. 

So, here’s the scenario: I’m writing a lot of code that deals with FIX messages.  FIX messages do not easily map to database structures, however certain parts of the average message are really useful for searching (generally, the order and execution references that allow you to reconcile the messages against other systems).  Now, this produces a use case which favours denormalization:

  • You can’t throw information away, so you have to log the full message in its native format.
  • Since this isn’t searchable, you need relational fields corresponding to some of the content of the message.
  • Furthermore, none of this is in any way related to the domain requirements of the original FIX message class.

So, really what you want to go is to create virtual properties that can be associated with your class, that NHibernate can use and nothing else.  This feature is called “Property Accessors”.  So, in my HBM file, you write:

<property column="ClOrdId" name="Tag11" type="String" access="ColourCoding.FixPropertyAccessor, ColourCoding" />

Which maps tag 11 of the FIX message to the “ClOrdId” column in the database.  FixPropertyAccessor is a class that implements NHibernate.Properties.IPropertyAccessor.  Now, when using custom accessors, NHibernate can’t use reflection to determine types.  This means that you will need to remember to use the type attribute to specify the target type. 

I’ve included an example at the bottom.  This one won’t compile until you delete the contents of the “Get” method, since the logic is specific to the application from which this is excerpted. 

Aside:  There is, in fact, a feature to allow the property accessor itself to give you this information, but it’s pretty much designed only for internal use.  If it just obtained the information from the IGetter’s target type, there wouldn’t be a problem.  Ho hum.

using System;
using System.Text.RegularExpressions;

using NHibernate.Properties;

namespace ColourCoding
{
    public class FixPropertyAccessor : IPropertyAccessor
    {
        public IGetter GetGetter(Type theClass, string propertyName)
        {
            return new FixProperty(propertyName);
        }

        public ISetter GetSetter(Type theClass, string propertyName)
        {
            return new FixProperty(propertyName);
        }

        class FixProperty : IGetter, ISetter
        {
            int _tagNumber;
            string _propertyName;
            TypeCode _typeCode;

            public FixProperty(string name)
            {
                _propertyName = name;
                _tagNumber = GetTagNumber(name);
                _typeCode = GetTypeCode(_tagNumber);
            }

            static TypeCode GetTypeCode(int tagNumber)
            {
                // Stripped down for clarity.
                switch (tagNumber)
                {
                    case TagNumbers.SendingTime:
                        return TypeCode.DateTime;
                    case TagNumbers.MsgSeqNum:
                        return TypeCode.Int32;
                    default:
                        return TypeCode.String;
                }
            }

            static Regex __tagRegex = new Regex(@"Tag(?<Id>d+)");

            static int GetTagNumber(string propertyName)
            {
                Match match = __tagRegex.Match(propertyName);
                if (match == Match.Empty)
                {
                    throw new ArgumentException(
                        string.Format("Property name '{0}' should be in the format 'Tag' followed by a number.", 
propertyName), "propertyName"); } int result; if (int.TryParse(match.Groups["Id"].Value, out result)) { return result; } throw new ArgumentException( string.Format(
"Property name '{0}' was in the correct format, but the numeric part did not parse as a number.", propertyName), "propertyName"); } public object Get(object target) { // Obviously, this part of the code will not compile on your machine. // I'm including it to give the general flavour of what you'll need to implement. FixMessageTracker tracker = (FixMessageTracker)target; FixMessage message = tracker.OriginalMessage; string value = _tagNumber == TagNumbers.MsgSeqNum
? message.Header[_tagNumber]
:
message[_tagNumber]; if (string.IsNullOrEmpty(value)) { return null; } switch (_typeCode) { case TypeCode.Int32: int result; return int.TryParse(value, out result) ? result : 0; case TypeCode.DateTime: return FixMessage.ParseDate(value); default: return value; } } public object GetForInsert(object owner, System.Collections.IDictionary mergeMap,
NHibernate.Engine.ISessionImplementor session) { return Get(owner); } public System.Reflection.MethodInfo Method { // We don't support this feature, so we return null get { return null; } } public string PropertyName { get { return _propertyName; } } public Type ReturnType { get { switch (_typeCode) { case TypeCode.Int32: return typeof(int); case TypeCode.DateTime: return typeof(DateTime); default: return typeof(string); } } } public void Set(object target, object value) { // You can't write to a denormalized FIX property. return; } } } }
Technorati Tags:

Gotcha: Don’t use anonymous delegates within loops

Okay, what do you think the following code prints?

using System;
using System.Collections.Generic;
using System.Linq;

class Program
{
static void Main(string[] args)
{
var strings = new string[] { "Hello ", "World" };
var actions = new List<Action>();
foreach (var s in strings)
{
actions.Add(() => Console.Write(s));
}
actions.ForEach(action => action());
}
}

If you think it says “WorldWorld”, you don’t really need to read the rest of this article.  You can skip to the section entitled “So you think you’re so smart”.

If, on the other hand, you think it prints “Hello World”, it’s worth explaining why the code doesn’t behave as expected.  The issue is the semantics of anonymous delegates.  Variables referenced within anonymous delegates are “live”.  If they change within the function, the latest value is used.  If they go out of scope, the last value is used.

The moral of this story is: don’t create a delegate in a loop, because it probably won’t do what you’re expecting.*  This bit me recently whilst trying to write code to stop a set of threads simultaneously.  The best option is to refactor the code and extract the line that adds in the action.  Of course, that gives you an ugly dialog box to deal with.

*Actually, any time the variable is changes before you use it, but loops are the most common case.

 

semantic-change

 

Actually, what the dialog is telling you is that extracting the method will result in the behaviour changing.  Luckily that’s what we actually want.  So, here you go, an even less elegant way to print “Hello World” on the console:

    static void Main(string[] args)
{
var strings = new string[] { "Hello ", "World" };
var actions = new List<Action>();
foreach (var s in strings)
{
AddAction(actions, s);
}
actions.ForEach(action => action());
}

private static void AddAction(List<Action> actions, string s)
{
actions.Add(() => Console.Write(s));
}

So you think you’re so smart

Okay, how about this code: 

    static void Main(string[] args)
{
var actions = from s in new string[] { "Hello ", "World" }
select new Action(() => Console.Write(s));
actions.ToList().ForEach(action => action());
}

If anyone can explain why this prints “Hello World” succinctly, there’s a beer in it.  The interesting things is that the “ToList” ensures that all of the actions are produced prior to execution, so it’s not to do with the co-routing aspect of Linq.  I believe it’s an example of why expressions of delegates and delegates are slightly different.  A more prosaic explanation would be simply to point out that Linq would be horribly broken if this didn’t behave.

Getting Started: How to Pause a Retlang Process Context

Well, in the words of Scott Hanselman “We’ll see how long this lasts.”.  Anyway, I should start as I mean to go on by providing some code that’s actually useful.

I’ve been using Mike Rettig‘s Retlang library a fair bit recently, and have nothing but praise for it.  I’ll go into more detail about why it’s great at a later date, but here I’ll just detail a problem that I encountered and how to solve it.

Let’s say that you’ve got a system that writes to the database and you need to bring the database down.  You need to stop your Retlang-using service from processing (or at least certain process contexts). 

Luckily, Retlang is a very well designed system with lots of injection points.  Here, we use the fact that each process context has an executor associated with it that actually processes the commands and we pause that.  There are the following design decisions worth understanding:

  • Retlang is heading increasingly towards a thread pool model, and that this code only works with the original “one thread per context” model.  If you used this in a thread pool model, it would not only pause the contexts you wanted to pause, but any contexts sharing the thread.
  • Batched commands are paused halfway through.  This behaviour is what I required, but it’s easy to change.
  • Existing running commands will complete.  This is desirable, since any process that could be paused mid-command could also be split into separate commands.
  • There’s no way to tell when the currently running commands complete.  This is unlikely to be a problem for you.

To use it, just create the context with this executor.  As you can see, the HaltingExecutor passes its commands onto an underlying executor.  This allows you to add logging or your own custom logic that you’ve already implemented.

using Retlang;
using System.Threading;

namespace ColourCoding.Parallel
{
public class HaltableExecutor : ICommandExecutor
{
ManualResetEvent _block = new ManualResetEvent(true);
ICommandExecutor _underlying;
bool _isHalted = false;

public HaltableExecutor()
{
_underlying = new Retlang.CommandExecutor();
}

public HaltableExecutor(ICommandExecutor underlying)
{
_underlying = underlying;
}

public void ExecuteAll(Command[] toExecute)
{
foreach (Command command in toExecute)
{
if (_block.WaitOne())
{
_underlying.ExecuteAll(new Command[] { command });
}
}
}

public void Halt()
{
lock (_block)
{
_isHalted = true;
_block.Reset();
}
}

public void Resume()
{
lock (_block)
{
_isHalted = false;
_block.Set();
}
}

public bool IsHalted
{
get
{
lock (_block)
{
return _isHalted;
}
}
}
}
}
Technorati Tags: ,