Disabling Foreign Key and Unique Checks in MySQL

30 06 2011

MySQL has a couple of Server System Variables which control your ability to violate constraints in DML or DDL for InnoDB tables. You can alter these variables dynamically by using the SET statement like so:

SET FOREIGN_KEY_CHECKS=0;
SET UNIQUE_CHECKS=0;

Where 0 means “turn these checks off”. Disabling foreign key checking can be useful for reloading InnoDB tables in an order different from that required by their parent/child relationships. Be warned that setting variables back to 1 does not trigger a scan of the tables data, anything inserted while it was turned off will not be checked for consistency.

Advertisements




Readonly vs. Const

29 06 2011

C# has two different versions of constant: compile-time (const) and runtime (readonly) constants. Compile-time constants are slightly faster but significantly less flexible than runtime constants.

Compile-time and runtime constants are accessed differently. Compile-time constants are replaced with the value of that constant in your object code. Runtime constants are evaluated at runtime, the IL generated references the readonly variable, not the value. Compile-time constants are limited to numbers and strings because these are the only types that can be replaced with literal values in the IL. Runtime constants can be any type, you must initialize them in a constructor or an initializer.

public const int BirthYear = 1982;

int myYear = BirthYear;
//compiles to the same IL as
int myYear = 1982;

The way in which the different constants are evaluated affects runtime compatibility across assemblies. When you reference a const in another assembly and that const changes BOTH assemblies must be recompiled to pick up the change (because the literal value is placed in the assembly IL). A change to a readonly value in another assembly does not require the referencing assembly to be recompiled, it still references to the correct value because it gets resolved at runtime.





Small Functions Help the JIT Compiler

28 06 2011

The CLR invokes the Just In Time Compiler on a function-by-function basis. Functions that do not ever get called do not get JITed. By factoring code into more, smaller functions rather than fewer larger functions you minimize the amount of extraneous code that gets JITed.

You can see this clearly using PerfMonitor (PerfMonitor runAnalyze program.exe) which provides some JIT compilation statistics. In my experiment the difference was apparent both in overall execution time and size of the native code created.

class Program
{
    static void Main(string[] args)
    {
        TestFunction();
        TestFunction2();
    }
    static void TestFunction(int control = 0)
    {
        if(control == 0)
        {}
        else
        {
          //lots of inline code
        }
    }

    static void TestFunction2(int control = 0)
    {
        if (control == 0)
        {}
        else if (control == 1)
        {
          //lots of inline code
        }
    }
}
  • Number of methods JIT compiled: 3
  • Total Size of Native code created: 2775 bytes
  • Average Native method size compiled: 925.0 bytes
  • Ratio of JIT compilation to CPU time: 6.1%
  • Total Duration: 372 msec
class Program
{
    static void Main(string[] args)
    {
        TestFunction();
        TestFunction2();
    }

    private static void func1()
    {
       //lots of inline code
    }

    static void TestFunction(int control = 0)
    {
        if(control == 0)
        {}
        else
        {
          func1();
        }
    }

    static void TestFunction2(int control = 0)
    {
        if (control == 0)
        {}
        else if (control == 1)
        {
          func1();
        }
    }
}
  • Number of methods JIT compiled: 3
  • Total Size of Native code created: 221 bytes
  • Average Native method size compiled: 73.7 bytes
  • Ratio of JIT compilation to CPU time: 3.7%
  • Total Duration: 355 msec




Using the Null-Coalescing Operator for Instantiation

27 06 2011

The null-coalescing operator is used to define a default value for reference types and nullable value types. It takes two operands, returning the left operatand if it is not null, otherwise it returns the right operand. I find it very useful when combined with properties to instantiate variables which can be null.

public class Book
{
   private String m_Title;

   public String Title
   {
       get
       {
          return (m_Title = m_Title ?? String.Empty);
       }
   }
}




Developer Working is not Tester Working

26 06 2011

There is a single tester on our team. The depth of her knowledge and her attention to detail astounds us most days. She knows the edge cases, the strange behaviours and the places where our code and the real world don’t quite agree with each other. There is definite truth to the saying that if you want to know how a system works, ask the testers! Something that she has taught me is that there is a vast difference between what I consider to be working code and what she considers to be working code.

Developer working is a rosy view of the world. Usually it means that the code works under some nice conditions. We assume the user has behaved sanely, the OS is in good shape, the machine is up and responsive etc. Tester working is a much tougher place to be. In tester working the end is nigh and all hell has broken loose. The user has decided to put all spaces in every field and delete our config files. The OS is a custom version that we’ve never seen before and the machine only responds twice a day.

Devs are optimists and testers are realists. I’m glad to have a tester who is so thorough in her understanding of the real world. It means I don’t have to be!





What did Unit Tests ever do for us Anyway?

25 06 2011

Six months ago my fellow dev and I were handed a new project to work on. We had just started to work together, our domain knowledge was zero, and 50% of us (me, that is) had zero experience of C#. The significant risk that this formula involved was obvious, especially on the faces of our project manager and the division head.

Something special was required. Luckily this guy would not shut up about this. Dependency inject he said, unit test he said. Having both experienced projects where the thought of changing code struck fear into our very hearts, we were up for giving it a go.

It started slow, that much is true. Writing one to two lines of test harness code for every line of “real” code is hard to accept. It’s counterintuitive given the business pressures you are under. Test code can be so simple that it feels worthless. Of course thing.Increment() returns thing+1, what else would it do?!

I felt that too, and often, but sticking with it (thanks to the support of the team as a whole) brought with it a significant reward. It is between doubt and boredom that magic happens.

Communication

Unit tests allowed a clear and concise communication of intent. For us this meant that we could compensate for some of our lacking in domain knowledge by increasing our ability to converse about the state of the code. I could easily point to a test to explain a problem I was having, instead of being stuck for words.

Code Quality

Code rot starts instantly. Having tests from the beginning allowed us to make sure that once the code was correct, it stayed correct. For a project where there were no gurus to save us this was incredibly valuable. Without unit tests to help us, plugging one hole would spring a leak elsewhere and we would almost certainly have ended up racing to the bottom as deadlines approached.

Knowing when we hit the Target

One pivotal component had to store and sort data on disk. We didn’t know how we would do that at first so we came up with the interface for the component and an in memory implementation. The tests for this interface acted as a target for us to hit when it came to implementing the on disk component. Once our on disk implementation passed the same tests we knew that our work was done and it satisfied the same criteria!

Testability gave us Flexibility

Making something testable through dependency injection means that it is also flexible. Having gone through this process we were able to port our application to multiple new DB platforms, each one taking roughly two days to complete. Each solution depends on the very same engine, we just had to write the custom pieces to be injected. Testability means being able to mock out parts of the system easily, those mockable parts make your system ultra-flexible.

We are on to another project now. One full of legacy code and no unit tests. Our eyes have been opened to what quality code can be and it is already influencing how we work on this new challenge. Try it and stick with it. Aiming for 100% test coverage but settling for 60% is enough to raise the quality of your code and your job satisfaction immeasurably.





Enabling the Dedicated Administrator Connection in SQL Server

24 06 2011

SQL Server provides a special diagnostic connection for administrators when standard connections to the server are not possible. This diagnostic connection allows an administrator to access SQL Server to execute diagnostic queries and troubleshoot problems even when SQL Server is not responding to standard connection requests. The DAC also allows you to query the system base tables you don’t normally have access to. To connect using the DAC, prefix the instance name with “admin:”.

Here are the runes to enable it:

sp_configure 'remote admin connections', 1;
GO
RECONFIGURE;
GO