views:

438

answers:

1

In my LINQ to SQL setup I have various tables which are mapped to classes which basically support the same interface to support versioning, i.e.

public interface IValid
{
    int? validTo { get; }
    int validFrom { get; }
}

The LINQ to SQL classes derive from this interface like this:

public partial class representationRevision : IValid
{
}

Now I would like to define a DRY (Don't Repeat Yourself) way of filtering EntitySet<T>, IEnumerable<T> and IQueryable<T> so that the resulting lists are valid for a specific revision. I've tried doing this:

public static class ExtensionMethods
{

    public static IQueryable<T> ValidFor<T>(this IQueryable<T> v, int? revision)
        where T : IValid
    {
        return v.Where(cr => ((cr.validFrom <= revision) &&
            ((cr.validTo == null) || (cr.validTo > revision)))
            || ((revision == null) && (cr.validTo == null))
            );
    }
}

But this gives problems on EntitySet<T>. I added a special implementation for EntitySet which first calls AsQueryable(), but this throws an exception. Undeterred I tried making a predicate so I could use the Where(predicate) approach:

    public static Expression<Func<contentRevision, bool>> IsValidFor(int? revision)
    {
        return ((cr) => ((cr.validFrom <= revision) &&
            ((cr.validTo == null) || (cr.validTo > revision)))
            || ((revision == null) && (cr.validTo == null)));
    }

When used with .Where<contentRevision>(IsValidFor(revision)) it gives errors like:

Error   5   'System.Data.Linq.EntitySet<contentRevision>' does 
not contain a definition for 'Where' and the best extension method overload  
'System.Linq.Enumerable.Where<TSource>
(System.Collections.Generic.IEnumerable<TSource>, System.Func<TSource,int,bool>)' has 
some invalid arguments

Note that this is even without using the IValid interface... I've been trying all kinds of variations on this theme (like adding the int parameter) but they all invariably seem to fail. Any pointers to get me in the right direction?

A: 

Not sure about EntitySet<T> so will focus on IQueryable<T> and IEnumerable<T>.

To allow the LINQ provider to evaluate the expression trees that IQueryable<T> uses for its expression arguments one needs to ensure the underlying interface is preserved. Otherwise do everything in term of IEnumerable<T> (i.e. if you are OK to pull the whole dataset into local memory and then process it there, rather than in the database, just use LINQ to Objects).

The other option is the AsQueryable extension method (part of Queryable class) which converts a IEnumerable<T> to a IQueryable<T>, and then you can share the rest of the code.

IQueryable<T> SomeSharedQuery(this IQueryable<T> source) {
    return source.(LINQ query operators...);
}
IQueryable<T> SomeSharedQuery(this IEnumerable<T> source) {
    return source.AsQueryable().SomeSharedQuery();
}

So you have the shared code, with an adapter method.

Richard
That works brilliantly, but not for EntitySet<T> though. The AsQueryable() does not have a translation to SQL (oddly enough).
Matthijs P
@Matthijs: Bawed on the docs `EntitySet<T>` implements `IEnumerable<T>` so you will get a match. Given `EntitySet<T>` is about lazy loading of parts of an existing query you don't gain anything from an `IQueryable<T>` implementation on it... if you want the db to do the work across the association include that in the original query.
Richard