Tomboy for windows

When working in Windows I like to use as much Open Source software as possible to make my environment as familiar to my Linux desktop as I can. I have many of the popular applications installed such as Firefox, Thunderbird, Gimp, MySql, and XEmacs (who said XEmacs wasn’t popular?!).

Recently a Tomboy preview for windows became available and a few nights ago I finally got round to installing on my laptop. Tomboy is a great application and works the way a note taking application should work.

The install is a little fiddly if you are running Vista due to a bug in the Gtk runtime installer, but it’s not too challenging to get running.

If you’ve ever wanted an application to quickly jot notes into I throughly recommend you give Tomboy a try.

NHibernate onFlushDirty has null previousState

The problem

We use an Entity interceptor to create audit records when we update most tables. We also do a lot of our data access through .NET remoting. This means that we open a session to load the object, the object is detached, serialized, modified, then reattached to the session when we want to persist the changes.

We noticed that in the cases where we are updating detached objects, although the update was being applied correctly there were no audit records appearing in the database. On investigation we realised that the previousState parameter passed into the onFlushDirty method of our interceptor was null.

Why

In the Save method of our data access class we were using the SaveOrUpdate method of the NHibernate session to persist the changes. Section 10.7 of the documentation states:

saveOrUpdate() does the following:

  • if the object is already persistent in this session, do nothing
  • if another object associated with the session has the same identifier, throw
    an exception
  • if the object has no identifier property, save() it
  • if the object’s identifier has the value assigned to a newly instantiated
    object, save() it
  • if the object is versioned (by a or ), and
    the version property value is the same value assigned to a newly instantiated
    object, save() it otherwise update() the object

and merge() is very different:

  • if there is a persistent instance with the same identifier currently
    associated with the session, copy the state of the given object onto the
    persistent instance
  • if there is no persistent instance currently associated with the session,
    try to load it from the database, or create a new persistent instance
  • the persistent instance is returned
  • the given instance does not become associated with the session, it remains
    detached

As our detached objects had an Id and version when we called SaveOrUpdate() they were being updated, and seeing as all update() does is reattach an object to the session, the session had no record of the changes that had been made to that object since it was loaded.

The solution

The solution was to use the merge() method (new in NHibernate 2.0). Merge() checks the first level cache to see if an object with the given identifier has previously been loaded. If so it loads that object out of the first level cache and updates it’s properties using the detached object. This means that the session is now able to track the changes made to the object so that when the flush occurs the previousState is no longer null.

NMock and out parameters

While trying to create a unit test the other day I came across the situation where my mock object needed to return a value via an Out parameter. A quick google turned up this post over at dev:ices.

I thought that had answered all my questions but when I tried it I kept getting a very unhelpful error:

—— Test started: Assembly: Tests.dll ——

TestCase ‘Tests.BatchOrderMessageHandlerTests.TestNMock’
failed: NMock2.Internal.ExpectationException : unexpected invocation of foo.DoFoo(, , out)
Expected:
1 time: foo.DoFoo(equal to , equal to , equal to ), will set c=, return [called 0 times]
at NMock2.Mockery.FailUnexpectedInvocation(Invocation invocation)
at NMock2.Mockery.Dispatch(Invocation invocation)
at NMock2.Mockery.MockObject.Invoke(Invocation invocation)
at NMock2.Monitoring.Invoker.Invoke(Invocation invocation)
at NMock2.Monitoring.ProxiedObjectIdentity.Invoke(Invocation invocation)
at NMock2.Monitoring.ProxyInvokableAdapter.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Tests.BatchOrderMessageHandlerTests.IFoo.DoFoo(Int32 a, Int32 b, Int32& c)
C:svnGLGParnters.TradeIdeasPositionManagersrcTestsBatchOrderMessageHandlerTests.cs(136,0): at Tests.BatchOrderMessageHandlerTests.TestNMock()

0 passed, 1 failed, 0 skipped, took 0.77 seconds.

A bit confused I quickly whipped up a trivial test as my unit test was a bit complicated and returned an enum as the Out parameter. My hypothesis was that NMocks couldn’t return an enum as an Out parameter.

public interface IFoo
{
int DoFoo(int a, int b, out int c);
}

[Test]
public void TestNMock()
{
IFoo foo = _mockery.NewMock();

Expect.Once.On(foo).Method(“DoFoo”)
.With(1, 1, Is.Out)
.Will(new SetNamedParameterAction(“c”, 2), Return.Value(1));

int result = 0;
int a = foo.DoFoo(1, 1, out result);

_mockery.VerifyAllExpectationsHaveBeenMet();
Assert.AreEqual(2, result);
}

This also failed so I checked what version of NMocks I was using. My NMock2.dll assembly had a revision number of 1.0.2313.18049. I downloaded the latest binaries from the NMock website. Checking the version number of the latest build shows it to be 2.0.0.44.

Rerunning the unit tests against this version of the NMock library everything now works!

So, if you’re having trouble with out parameters in your NMock mocks, upgrade your build version.

NHibernate 2.0 and the join table syntax

I’ve noticed my post on Mapping a view with NHibernate is always quite popular. Resorting to mapping from a view has worked fine in the past as long as you only required read access, but if you wanted to build a complex object relational mapping that you could update you were in trouble…

Until Now

With NHibernate 2.0 recently being released we now have access to the join table syntax in our mapping documents. This means we can now build more sophisticated domain objects that map on to more than one table. NHibernate takes care of the multi-table inserts and updates behind the scenes making your life easier.

This has to be one of the most underrated features of NHibernate 2.0 as it finally allows you to break away from the one to one mapping between domain objects and your relational model which has ultimately caused compromises in the past.

I urge you to check out this and the other fantastic new features available in the latest NHibernate release.

Mono bugs fixed; Spring.Net support coming soon!

I’ve managed to get all my Mono patches committed in time for 2.0 which be released very soon. Bugs I’ve fixed are:

#325128 ConfigurationSection.GetRuntimeObject
#395209 Fix incompatibility in the HierarchicaDataBoundControl
#397612 Mutually exclusive behaviour between Mono and MS.NET for xs:import

As well as a couple of other fixes I didn’t create bugzilla bugs for:
The TypeDescriptor bug which I blogged about a while ago, and another XmlSchema bug where Uri.OriginalString wasn’t being returned in the correct case.

Hopefully with these Mono bugs fixed in the latest release the major barriers to getting Spring.Net support finished and committed in will be removed. I’m in the process of working through my patch with Mark Pollack, so all going well we may see some Mono support in the next Spring.Net release.

Patching Mono

I submitted a fix for bug #325128 last night which was the last of the four patches needed get Spring.Net working on the Mono runtime. So far I’ve submitted patches for:

  • TypeDescriptor
  • XmlSchema
  • HierarchicalDataBoundControl
  • ConigurationSection

So far only the TypeDescriptor patch has been accepted and committed to the repository, but hopefully the other three won’t be far behind. It’s quite important to us that these patches make it into the 2.0 release so we can just use the official builds rather than having to build from source ourselves.

Using MySQL in heterogeneous environments.

If like us you have a requirement to run MySQL in a mixed Windows and Linux environment and you want your database to be portable you will need to change the default case sensitive table name behaviour of MySQL on one of the operating systems. On Windows the default behaviour is case insensitive, on Linux the default behaviour is case sensitive.

I like my table names to stay in the same case I scripted them in so we chose to change Windows to be case sensitive. The fix is pretty simple – you just need to add the following line to your my.ini after [mysqld] and restart your mysql service.

lower_case_table_names = 0

Existing objects won’t suddenly change case, but any new tables you add to your database will appear in the same case you scripted it in. See the mysql documentation for more details.

Spring.NET on Mono

It’s been a while since my last post because I’ve been extremely busy hacking away to get Spring.NET working on Mono. I’ve basically got a working solution now so we should hopefully get the changes committed back into the Spring.NET repositories in the next couple of weeks.

It’s been a bit of an interesting road so far – transistioning our application onto Mono – and I am a bit surprised at how many framework bugs I’ve discovered. I’ve submitted one patch so far for a very minor bug in the TypeDescriptor class, however I still have three more patches to write and submit at this point. I wouldn’t have thought that the parts of the framework we are using were especially esoteric but perhaps I’m wrong.

Now all I need is stepping debugger integration in MonoDevelop and I won’t have to boot into Vista ever again!

Url Rewriting and the dreaded “Cannot use a leading .. to exit above the top directory”

I’ve just had a fun couple of hours trying to figure out why my site suddenly starting giving me this exception:

Exception type: HttpException
Exception message: Cannot use a leading .. to exit above the top directory.

It turns out that ASP.NET 2.0 doesn’t like playing nicely with Url Rewriters. The problem occurs when the rewriting rebases the form action path. e.g instead of having your form tag look something like this:

<form id=form1 method=”post” action=”page.aspx?id=whatever” name=”form1″>

After rewriting it ends up looking like this:

<form id=form1 method=”post” action=”../page.aspx?id=whatever” name=”form1″>

This obviously is not a good thing. For a detailed breakdown of the problem I suggest you read sgerz’s post Get GoogleBot to crash your .NET 2.0 site.

In my particular case I am using an open source url rewriter solution from http://urlrewriter.net. Of course the beauty of it being open source is that you can fix the problem! So a one line change on line 80 of HttpContextFacade.cs from:

HttpContext.Current.RewritePath(url, false);

to

HttpContext.Current.RewritePath(url, true);

solved the problem.

So why did this start happening all of a sudden? I can only surmise that it had something to do with the fact that I had just installed Vista SP1 and that caused cassini to start behaving as IIS 6.0 does.

I’ll be emailing the maintainers of the project to see if they want to make the change to the main repository.