Okay, I'm playing around with SqlClr (doing runtime DDL stuff, mainly), and I discovered that SqlClr and anonymous delegates don't play along very well. The issue is that code like this:

CallWithAction(delegate(DateTime dt) { return dt; } );

Is actually translated to something like this:

if(ClassName.<> HiddenFieldName == null) 
            ClassName.<> HiddenFieldName = new SomeDelegate(HiddenMethodName);
CallWithAction(ClassName.<> HiddenFieldName);

And that causes problem with the SqlClr, since the method is trying to store into a static field, which doesn't seem to be allowed on the safe level (which I really don't want to pass.)

It doesn't happen if the anonymous method uses local variables, since then the compiler generate a completely new class. Just a little gotcha that I would've never solved without Reflector.

Seems like I made a mistake in the previous post. The problem with the Turkish I wasn't supposed to be solved on the Reflection API level, but earlier than that. The issue seem to be the string transformation done on a property name (for instance, if I want NHibernate to use the field and not the name) rahter than what I pass to GetField() and deriatives) where NHibernate didn't took into account that lowering the case of a character may result in a different letter on other locales. The issue was already fixed on NHibernate CVS, and I'm feeling stupid for crying wolf.

I've just got an email about an interesting problem with NHibernate. After searching for a little while, I came up with the conclution that the problem is in the framework, and I can't see an easy solution for it.

First, let's start by explaining Turkish locale & its unique interpretation of the humble i letter. This MSDN article does it best, so I'll let them do the job:

For nearly all Latin alphabets, including U.S. English, the character i (\u0069) is the lowercase version of the character I (\u0049). This casing rule quickly becomes the default for someone programming in such a culture. However, in Turkish ("tr-TR"), there exists a capital "i with a dot,"  character (\u0130), which is the capital version of i. Similarly, in Turkish, there is a lowercase "i without a dot," or (\u0131), which capitalizes to I. This behavior occurs in the Azeri culture ("az") as well.

How does it has anything to do with NHibernate? Well, consider this code:

This code will fail to return anything if the locale is set to Turkish. And the problem is worse because there doesn't seem to be a way to pass an InvariantCulture or Ordinal to the GetField method. The only solution that I can see now if to get all the fields on the method and iterate over them one by one, making a culture insensitive comparision.

Please tell me that I'm missing something, since this seems to indicate that any Reflection code will likely break if you're using the Turkish locale.

Oh, and that is the behavior for both .Net 1.0 & .Net 2.0

I just read this post from an ex-googler, talking about how they tried to move from MySQL to another (presumbely Enterprise. Most likely DB2 or Oracle), and failed. I'll gloss over the fact that they implement such a critical system over a database with no trasaction support (and the comments about "it is easy to add on the application level" that made me cringe so hard that for a moment I looked like a fat bagel).

I want to talk about migrating a single application from one database to another. This is not something that you see done often when you're talking about Line of Business application. Especially not in-house one. But, and this is important, it's both possible and straight-forward in most cases if (and only if) you know something about layering and seperated the database from the rest of your application properly.

If my recent ActiveRecord & NHibernate would ever need to support anything beyond SQL Server, here are the list of steps that I would need to do:

• Create an equivalent schema for the other database (most probably automatically via some tool).
• Research on how the connection string looks like and put it in the config file.
• Re-write a single trigger, which is done in T-SQL for efficently.
• Run the tests against the new database.

Total time that this should take is two days, and I'm including in that the time that it will take me to install the database (even if it's an Oracle) and then learn its SQL deriative.

Now, that is not to say that I might get into places where the application relies on some SQL spesific behavior (identity columns, for instance), or something similar, but those should be isolated incidents. The application itself should move without anything major happening. You know, if I didn't have NHibernate, I would have had to re-write all the queries from scratch, and that might have added a week or so if I had really complex queries (I honestly don't know, NHibernate handles it all). But the application would still not know that anything had happened. The one caveat that may happen is if I needed to port it to something like MySQL 4.0, which doesn't support Transactions, Nested Queries, etc.

This is ABC in application design. The inability to move from one database to the other means that your application relies on way too much on database spesific stuff. There may be reasons for this, but I think that saying something like: "You get what you pay for, and with free you get much more..." is bullshit.

Okay, the code is in the Subversion repository, but I'm not ready to release it yet. I've a shameful confession to make first:

I never used an IList with NHibernate (or ActiveRecord) before, so I'm not really sure whatever my code makes good sense or not. And, in addition to that, I haven't had the time to test it propertly. I would appriciate it if someone who had used it before could take it for a spin and tell me what they think the bad points are.

I'm running ReSharper #213, and it's aweful. Exceptions are all over the place. The problem is that it is so feature packed that I have a hard time living without it. I just had an instance where doing a refactoring on R# caused the entire IDE to vanish.