relax! it’s just 0s and 1s

so in my last post, I wrote about the Linq compiled queries syntax, before diving into its use. this post is about the usage of compiled queries.

every time, a Linq Query is executed (accessed), the expressions tree/Linq query is translated into its equivalent SQL/data source query and the results are fetched. for static data and data, changing on parameter values, the repeated translation is redundant.

Assume we have the following methods:

GetAllProductsAuthorizedToBeSoldInIndia()
{
 // Linq query to join Products and Country table on key for 
 // India and return the expected products.
}

now if we access this method N times, the LINQ query will have N SQL translations, for the same result that it will fetch. clearly this is a performance bottleneck.

also consider a parameterized method:

GetAllProductsAuthorizedToBeSoldInACountry(int countryId)
{
 // Linq query to join Products and Country table on 
 // CountryId and return the expected products.
}

Except for the parameter value, the generated SQL query has to be re-generated every time.

To solve this, we use Linq Compiled Queries. They facilitate one time translation of the Linq query, and re-use of the translated query across multiple calls.

public class MyCompiledQueries
{
  private static 
  Func<MyDatabaseContext, IQueryable<Product>> 
  ProductsAuthorizedToBeSoldInACountry 
  = CompiledQuery.Compile(
  (MyDatabaseContext db, int countryId) => 
  db.Products(p=>p.CountryId=countryId)); 
 
  public static List<Product>  
  GetAllProductsAuthorizedToBeSoldInACountry
  (MyDatabaseContext db, int countryId)
  {
    return MyCompiledQueries. ProductsAuthorizedToBeSoldInACountry(
    db, countryId).ToList<Product>();
  }
}

the queries are translated once, and the parameter values are substituted at runtime.

1. The CompileQuery.Compile method returns us a delegate, which can be invoked repeatedly.
2. The appropriate parameters need to be passed to the delegate during the invocation. (data context + query parameters)
3. Because we need to reuse the delegate to actually have any performance benefit, static variables/method wrappers are preferred.
4. It is a good practice to put all of your Compiled Queries into a separate class, at one place, and possibly have wrapper methods which make more business sense than entity names.
5. on my box, performance increased by 220%, when I changed my queries to Compiled Queries. I was working on a test domain data application using Linq. this was just slightly less than the data reader performance, we get.

the syntax for compiled queries makes it a little tough to maintain, but the benefits are sweet n totally worth the effort.

I wanted to blog about Compiled queries in LINQ in this post. However, before doing that, I realized it would be good if I wrote something about the foundation on which the Compiled Query syntax is built.

This is because the call to a Compiled Linq Query involves calling the Compile() method:

public static Func<TArg0, TArg1, TResult> 
 
CompiledQuery.Compile<TArg0, TArg1,  TResult>
 
(Expression<Func<TArg0, TArg1, TResult>> query)
 
 where TArg0 : DataContext;

Now if the above syntax makes total sense to you, then you are probably over the following words. Else, you could read on to make sense of the above syntax.

Assume we have a delegate type defined as follows:

delegate int MyDelegateType(int a, int b)

this delegate can contain (thinking of code container) all methods which return ‘int’ and take 2 integer parameters.
E.g.

public int AddMethod(int a, int b)
 
MyDelegateType myDelegateObject = new MyDelegateType(AddMethod);

As you know, C# 2.0, simplifies this synax. we can now do:

MyDelegateType myDelegateObject = AddMethod;

looks good so far..

Now suppose, we make the delegate deal with generic types.

delegate T MyGenericDelegateType<T> (T a, T b)

this delegate can contain all methods which return ‘T’ type and take 2 T type parameters.

MyGenericDelegateType<int> myGenericDelegateObject = AddMethod;

Now, this is the AddMethod

public int AddMethod(int a, int b)
{
  return a + b;
}

As you know using C# 2.0 anonymous methods, we could write:

MyGenericDelegateType<int> myGenericDelegateObject =
delegate (int a, int b) { return a + b };

C# 3.0, further simplifies this anonymous method syntax, by eliminating even the delegate keyword, and getting the => operator. (Lambda Expressions coming in..)

Hence in C# 3.0, we can write:

MyGenericDelegateType<int> myGenericDelegateObject =
(int a, int b) => return a + b;

A further simplification to the above syntax is removing the types declared. This is because C# 3.0 is equipped with the type inference feature.

MyGenericDelegateType<int> myGenericDelegateObject = (a,b) => a + b;

Notice how we removed even the return keyword. This is perfectly valid, if the method contains only a single return statement.

Now the System.Linq namespace already defines some generic delegates for us. e.g. One of them is:

public delegate TResult Func<A0, A1, TResult> (A0 arg0, A1 arg1);

What this means is we don’t need to define our own delegate types, every time we want to use one with a similar signature.

we could directly say:

Func<int, int, int> myLinqDelegateObject = AddMethod;

Here TResult, A0 and A1 are int types. Replacing by lambda expressions,

Func<int, int, int> myLinqDelegateObject = (a,b) => a+b;

We can use this delegate object as

int sum = myLinqDelegateObject(3, 4);  // sum = 7;

Here myLinqDelegateObject is nothing but a delegate object (instance), of a delegate type already defined by the System.Linq namespace.

An Expression Tree is nothing but an object of type

System.Linq.Expressions.Expression<TDelegateType>

, where TDelegateType is the delegate the tree represents.

e.g.

Expression<Func<int, int, int>> myExpressionTreeObject = (a,b) => a+b;

Expression trees are nothing but an in memory representation of code. sort of a mini code segment, which can be evaluated later on demand, and can be built upon.

Based on all the points above, if we see the syntax now:

public static Func<TArg0, TArg1, TResult> 
 
CompiledQuery.Compile<TArg0, TArg1,  TResult>
 
(Expression<Func<TArg0, TArg1, TResult>> query)
 
 where TArg0 : DataContext;

It should look clear that, the Compile method takes in an Expression Tree object (query), of which the first parameter should be of type DataContext (Generic Contraint), and the return type is a Delegate object. Func

So the use of the Compile method would be as follows:

var queryDelegate =  CompiledQuery.Compile(
 
  (MyDataContext db, string param1, string param2) =>
 
  db.MyEntity
     .Where(v => v.Column1.Trim().ToLower() == param1.Trim().ToLower())
     .Where(v => v.Column2.Trim().ToLower() == param2.Trim().ToLower()));

Here queryDelegate is of type:

Func<MyDataContext, string, string, IQueryable<MyEntity>>

and can be used as follows:

var MyEnitities = queryDelegate(db, param1value, param2value);

As you can see, concise delegate syntax ( => ), generics (T), anonymous methods/types (var), type inference (var), lambda expressions (=>) etc, work under the hood for the Compile method. C# 3.0 is cool.

As for the exact use of Linq compiled queries, their advantages and disadvantages, I’ll be writing about it in part 2 of this post..

 When I started with the terms, I was a bit confused on the order/meaning of the following in the software release life cycle: alpha, beta, gamma, CTP, RTM, RTW, RC, GA, Gold, Box Copy etc…

I decided to get clear on these terms with the help of my friend, Wiki. So completely based on it, here is the quick summary of the release cycle stages, their order and meaning..

1. Pre-Alpha: Not feature complete, refers to all activities prior to Software Testing. e.g. Milestone versions, Nightly builds etc
2. Alpha: Build delivered to the internal Software Testers for testing.
3. Beta: (also known as Preview, Prototype, Technical Preview or Community Technical Preview Release stage): Build which has passed alpha testing and has been released to external customers/prospective customers (acting as free beta testers) for external feedback/improvements.
4. Release Candidate (RC): (also known as Golden Master, Gamma, Delta, Omega, Zenith etc): A code complete version with potential to be a final product, with no fatal bugs/showstoppers.
5. Gold (also known as General Availability Release GA): Production or Live version of a particular product. ready for distribution.
6. Release To Manufacturing (RTM): Used when the Gold version is sent to a product manufacturer for physical distribution (CDs, DVDs etc) Box Copy is the term used for this physically created version of the product.
7. Release To Web (RTW): If the RTM distribution is online, RTM is called as RTW.

Always good to know the terms once, and be clear forever.

Source: http://en.wikipedia.org/wiki/Software_release_life_cycle

as explained in my previous post, we can easily test the public methods of a class. At the end of that blog, I mentioned about private accessors. this post explains that cool feature.

assume we have a class as follows:

public class BusinessObject
{
    private const int MagicFactor = 18;
 
    private int CalculateConfidentialValue(int baseAmount)
    {
        return baseAmount * BusinessObject.MagicFactor;
    }
}

obviously, the method and magic factor are not super-confidential or anything. but let us pretend, they are.

here both the constant and the method are private. needless to say, the following Test Method won’t compile.

[TestMethod()]
public void WontCompileCalculateConfidentialValueTestMethod()
{
    BusinessObject myObject = new BusinessObject();
 
    int magicFactor = BusinessObject.MagicFactor;
 
    Assert.AreEqual(18, magicFactor);
    Assert.AreEqual(magicFactor * 2, myObject.CalculateConfidentialValue(2));
}

this is where private accessors help us. Private Accessors help us to access the Private members and Methods of an object, so that we can unit test them.

1. go to the BusinessObjects class file
2. Right Click >> Create Private Accessor >> Test project..

something similar is created behind the scenes:

[Shadowing("PrivateAccessorDemo.BusinessObject")]
public class BusinessObject_Accessor : BaseShadow
{
    protected static PrivateType m_privateType;
 
    [Shadowing(".ctor@0")]
    public BusinessObject_Accessor();
    public BusinessObject_Accessor(PrivateObject __p1);
 
    [Shadowing("MagicFactor")]
    public static int MagicFactor { get; }
    public static PrivateType ShadowedType { get; }
 
    public static BusinessObject_Accessor AttachShadow(object __p1);
    [Shadowing("CalculateConfidentialValue@1")]
    public int CalculateConfidentialValue(int baseAmount);
}

you don’t need to try and understand that. all you need is how to use the created code, and here it is:

[TestMethod()]
public void CalculateConfidentialValueTestMethod()
{
    BusinessObject_Accessor target = new BusinessObject_Accessor();
 
    int magicFactor = BusinessObject_Accessor.MagicFactor;
 
    Assert.AreEqual(18, magicFactor);
    Assert.AreEqual(magicFactor * 2, target.CalculateConfidentialValue(2));
}

As we can see, we could now test the Private Member and the Private Method using the accessor.

Another good thing about the private accessors now, is the way we can test for exceptions thrown by the method.

Assume we modify our source method to:

public class BusinessObject
{
    private const int MagicFactor = 18;
 
    private int CalculateConfidentialValue(int baseAmount)
    {
        if (baseAmount == 0)
        {
            throw new ArgumentException("argument cannot be zero.", "baseAmount");
        }
 
        return baseAmount * BusinessObject.MagicFactor;
    }
}

To test, if an argument exception is indeed thrown, we could write an unit test case as follows:

[TestMethod()]
[ExpectedException(typeof(System.ArgumentException))]
public void CalculateConfidentialValueWithZeroParameterTestMethod()
{
    BusinessObject_Accessor target = new BusinessObject_Accessor();
    target.CalculateConfidentialValue(0);
}

1. I believe this is possible, because of the Shadowing attribute which is now used for private accessors changing the way exceptions are returned by the target object.
2. Before the Shadow based reflection, the accessor always threw a System.Reflection.TargetInvocationException and the inner exception needed to be evaluated.
3. The concise attribute based exception check for ArgumentException could not be checked.

Private Accessors are very useful, when you are testing the Business Layer or OM.

there’s a solution to every problem; given enough time and money..

No dev shall be held to answer for a bug, or otherwise infamous defect, unless on a triage or request of a VP, except in cases arising in the penultimate or ultimate releases, or in a Red Alert, when in actual service in time of Bug War or Job Security; nor shall any dev be subject for the same code defect to be twice put in jeopardy of mind or fingers; nor shall be compelled in any bug fix to be a code defect against himself, nor be deprived of snacks, games, or soda, without due process of triage; nor shall private work items be taken for public bug fixing, without just compensation.

– intended for reading/laughing/forgetting purposes only