Question

I’m using Entity Framework 4.1 Code First. In my entity, I have three date/time properties:

public class MyEntity
{
    [Key]
    public Id { get; set; }

    public DateTime FromDate { get; set; }

    public DateTime ToDate { get; set; }

    [NotMapped]
    public DateTime? QueryDate { get; set; }

    // and some other fields, of course
}

In the database, I always have the From/To dates populated. I query against them using a simple where clause. But in the result set, I want to include the date I queried for. I need to persist this for some other business logic to work.

I’m working on an extension method to do this, but I’m running into problems:

public static IQueryable<T> WhereDateInRange<T>(this IQueryable<T> queryable, DateTime queryDate) where T : MyEntity
{
    // this part works fine
    var newQueryable = queryable.Where(e => e.FromDate <= queryDate &&
                                            e.ToDate >= queryDate);

    // in theory, this is what I want to do
    newQueryable = newQueryable.Select(e =>
                                           {
                                               e.QueryDate = queryDate;
                                               return e;
                                           });
    return newQueryable;
}

This doesn’t work. It works if I use an IEnumerable, but I want to keep it as IQueryable so everything runs on the database side, and this extention method can still be used in any part of another query. When it’s IQueryable, I get a compile error of the following:

A lambda expression with a statement body cannot be converted to an expression tree

If this was SQL, I would just do something like this:

SELECT *, @QueryDate as QueryDate
FROM MyEntities
WHERE @QueryDate BETWEEN FromDate AND ToDate

So the question is, how can I transform the expression tree I already have to include this extra property assignment? I have looked into IQueryable.Expression and IQueryable.Provider.CreateQuery – there’s a solution in there somewhere. Maybe an assignment expression can be appended to the existing expression tree? I’m not familiar enough with the expression tree methods to figure this out. Any ideas?

Example Usage

To clarify, the goal is to be able to perform something like this:

var entity = dataContext.Set<MyEntity>()
                        .WhereDateInRange(DateTime.Now)
                        .FirstOrDefault();

And have the DateTime.Now persisited into the QueryDate of the resulting row, WITHOUT having more than one row returned from the database query. (With the IEnumerable solution, multiple rows are returned before FirstOrDefault picks the row we want.)

Another Idea

I could go ahead and map QueryDate like a real field, and set its DatabaseGeneratedOption to Computed. But then I would need some way to inject the “@QueryDate as QueryDate” into the SQL created by EF’s select statements. Since it’s computed, EF won’t try to provide values during update or insert. So how could I go about injecting custom SQL into the select statements?

Answer 1

Thank you for all of the valuable feedback. It sounds like the answer is “no – you can’t do it that way”.

So – I figured out a workaround. This is very specific to my implementation, but it does the trick.

public class MyEntity
{       
    private DateTime? _queryDate;

    [ThreadStatic]
    internal static DateTime TempQueryDate;

    [NotMapped]
    public DateTime? QueryDate
    {
        get
        {
            if (_queryDate == null)
                _queryDate = TempQueryDate;
            return _queryDate;
        }
    }

    ...       
}

public static IQueryable<T> WhereDateInRange<T>(this IQueryable<T> queryable, DateTime queryDate) where T : MyEntity
{
    MyEntity.TempQueryDate = queryDate;

    return queryable.Where(e => e.FromDate <= queryDate && e.ToDate >= queryDate);
}

The magic is that I’m using a thread static field to cache the query date so it’s available later in the same thread. The fact that I get it back in the QueryDate’s getter is specific to my needs.

Obviously this isn’t an EF or LINQ solution to the original question, but it does accomplish the same effect by removing it from that world.