Question

I’m extending some Linq to SQL classes. I’ve got 2 similar statements, the 1st one works, the 2nd does not (“has no supported translation to SQL” error).

var reg2 = rs.ProductRegistrations().SingleOrDefault(p => p.Product.product_name == "ACE")

var reg5 = rs.ProductRegistrations().SingleOrDefault(p => p.product_name == "ACE");

After reading this link LINQ: No Translation to SQL

I understand (I think), that basically everything needs to be “inline”, otherwise the expression tree can not be calculated correctly. The 1st example directly accesses the LinqToSql EntitySet “Product” (keeping everything inline), whereas the 2nd example uses a property that is defined like this:

public partial class ProductRegistration :IProduct
{
    public string product_name
    {
        get { return this.Product.product_name; }
    }
}

I’m assuming my problem is that LinqToSql cannot translate that.

How would I turn a “property” into an equivalent statement? I know I need to use the System.Linq.Expressions.Expression, but everything I’ve tried doesn’t work (some don’t even compile). Maybe I should make an Extension method (using Expression), and then call that from the property? Can a property call an extension method??

Things like below don’t work:

public static System.Linq.Expressions.Expression<Func<IProduct, bool>> ProductName2 (string pname)
{
    return (p => p.product_name == pname);
}

Bottom line, I know I need to wrap my access method in an “Expression<….>” but I don’t know how to access that from the property, so that the “reg5” variable above will work correctly.

Would be great if there was some magic attribute that I could just add to the property to “auto-expression” the property and make LinqToSql happy, instead of wrapping it in Expression<…>

Would love to be able to do this…

public partial class ProductRegistration :IProduct
{
    [Auto-Expression]
    public string product_name
    {
        get { return this.Product.product_name; }
    }
}

EDIT
The link and answer below works. Awesome, thanks. 2nd part of my question, again I’ve got 2 similar statements, the 1st one works, the 2nd does not (“has no supported translation to SQL” error).

var reg = rs.ProductRegistrations().ProductName("ACE").WithTranslations().SingleOrDefault();

var reg2 = rs.ProductRegistrations2().ProductName("ACE").WithTranslations().SingleOrDefault();

The difference in them is that the 1st one returns an IQueryable of a concrete class “IQueryable[ProductRegistration]”, whereas the 2nd one returns an IQueryable of an interface “IQueryable[IProduct]”. I would like to use the 2nd one, because I can slap the interface across many different classes and it’s more generic that way, but it seems to not work. Any ideas?

Answer 1

Would be great if there was some magic attribute that I could just add to the property to “auto-expression” the property and make LinqToSql happy, instead of wrapping it in Expression<…>

There is, very nearly. You’ll still have to do some work, but Damien Guard and friends have done the hard part for you: Client-side properties and any remote LINQ provider

The cool thing is that it works with any LINQ provider which supports the Expressions you use.

Update: The problem with your second version (with the interface) is that the Queryable provider would need to be able to figure out what the implementor of the interface is, because it needs to transliterate that into a table name. But the whole point of an interface is that the interface user should be agnostic as to the implementing type, so the provider would be working at cross purposes with the interface. So I don’t think the second form will work.