NHibernate doesn’t stop you when you try to query something it does not know about

I recently upgraded a system from using NHibernate 4 to using NHibernate 5. The upgrade itself was uneventful. Apart from a minor interface change in IUserType, everything kind of went smoothly. As soon as everything compiled, I started the system and… nothing happened.

There were no crashes, there were no exceptions, but all queries returned zero results. Strange.

I fired up NHProf. No SQL showed up, no queries were fired against the database. Yet I can step through my data-access code without hitting exceptions.

As it turns out, NHibernate does not stop you (by throwing an exception) from querying entities it does not know how to query. Instead, it just returns an empty collection of the type you’re attempting to query. I wasn’t expecting that.

So if you ever run into this issue, make sure to check whether you have loaded your class mappings.


Running EventStore as a Windows Service

I’ve been experimenting with EventStore lately. So far it appears to be a great product. The documentation is both good and bad. There is very, very little documentation, yet everything seems to be there. You just need to know where to dig, or watch/read some of the internals videos/blog posts.

The product ships as a simple command line application. That’s great, because it gives you all the flexibility you want. But you probably want to run it in the background as a service anyway so let’s do that.

I set up my machine to support multiple versions without having to change my service definition with every product upgrade. So I created the following drive structure

  ├─latest (--> ./4.0.3-hf1)

where latest is an NTFS junction point to the directory containing the binaries for the latest version. When a new version is released, I can just change to junction point to the newest version.

Next step is to create a Windows Service but EventStore.ClusterNode.exe cannot run as a service directly so you need to wrap it inside a service wrapper like NSSM or winsw. I chose the latter simply because it looked to be the most foolproof to me. I downloaded the WinSW.NET4.exe binary from the releases tab, copied it to C:\EventStore and then renamed it to EventStore.ServiceWrapper.exe. To finish the configuration of the service wrapper, all I needed is an xml file with the service definition in it. Here’s mine.

  <arguments>--db=%BASE%\data --log=%BASE%\logs --run-projections=all --start-standard-projections=true</arguments>

Finally, we need to install/register the Windows Service by calling

C:\EventStore> EventStore.ServiceWrapper.exe install

in a shell with administrative privileges (Windows button + X > Command Prompt (Admin)). Using that shell, you can also start the service

C:\EventStore> net start EventStore

Easy, right?

Software Engineering

Best practices

I while ago, somebody came to me and asked whether I have a list of best practices somewhere. I don’t and I don’t believe I should.

In my opinion, “best practices” don’t exist, they are merely practices. They work for some, they won’t work for others.

And that in itself is the most important thing to realize. A practice can be good or can be bad (or “best” for that matter), but only in a certain context.

So instead of making lists of good/best practices, I’ll search for some practices or make them up, compare them extensively within the context they’ll be applied to, and then pick one carefully.