Wednesday, April 25, 2007

DLINQ and Projection Operator

Seems I was impressed too early. Projection operation on DLINQ is giving me a bit of grief:

var list = from p in prods

       where p.UnitPrice > 30

       select new {


          Description = string.Format("{0} - {1}",

              p.ProductName, p.UnitPrice)


I got the following exception:


Yeah, I know String.Format can’t be translated to SQL, but I’m expecting it to be executed as .NET code. DLINQ is already using CodeDom to generate database access code anyway. Why can’t it generate the SQL that retrieves only directly mapped columns/fields, then produce the rest fields in the anonymous type, like this:

class _AnonymousType


    //map to database columns

    private int     _productID;

    private string  _productName;

    private decimal _unitPrice;



    //generate Description as

    public string Description {

        get {

            return string.Format("{0} - {1}",






Sure, this would require the Projection Operator be part of the expression tree and the anonymous type being generated at runtime, rather than by the compiler, as it currently is. But limiting the projection in DLINQ to only these operations that can be translated in SQL is probably too much of a sacrifice… In the example above, we can change string.Format to:

     Description = p.ProductName + "-" + p.UnitPrice

 But what if the projection involves more complicated function calls?