Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Query: TimeSpan with DateTime arithmetic operations are not supported #6025
Edit by @divega:
Fixing this issue is not necessarily about fixing the overflow or type inference problems we hit immediately with the different expressions in this bug but about finding translations of those expressions that actually work. Likely when we find expressions like this we could transform at least some of them into a combination of
Original customer report
After updating from RC1 this issue with
Further technical details
DB: Azure SQL DB
EFC 2.0 RC
Well, year has passed, still can't work with
Notes for triage: Looks like a couple of different things are happening here. In original bug, TimeSpan was being converted to Time, but the value overflowed. This is somewhat expected since the mapping for TimeSpan is to Time, but Time can easily overflow. This is discussed in #242 for mapped properties.
The new exception is different--it indicates that query is attempting to create a DateTime parameter but using a TimeSpan object. SqlClient cannot handle this and so throws. I suspect this is happening due to type inference in the query pipeline, but I haven't verified this.
So, fundamentally, this issue is not about the general mapping of TimeSpan, which is covered by #242, but instead is about what query should do when translating this either in terms of creating parameters of the "correct" type (which can overflow) or doing some more complex translation which avoids this.
@AsValeO As a workaround, you can force client evaluation of the query:
q = q.ToList().Where(x => x.Added + TimeSpan.FromDays(3) >= DateTime.Now);
Before RC1 client evaluation was likely happening all the time, which is why it appeared to be "working".
Another workaround is to calculate the deadline on the client:
var deadline = DateTime.Now + TimeSpan.FromDays(3); q = q.Where(x => x.Added >= deadline);
But both of these workarounds suffer from
The best work around to achieve this in SqlServer would be to use
var bs = await db.Building.AsNoTracking() .Where( x => DateTime.Now > x.AddDate.AddDays(30)).ToListAsync();
If you are using different
It will also avoid issue of overflow.
There are multiple issues around this area.
Closing the issue as the work-around translate to server & also avoid overflow issue. We can address client eval or future translation if there is enough customer feedback.
I throw my obvious suggestion here too:
Map it like this:
It would not cover microseconds but I think most often TimeSpans need values greater than 24 hours, than precision of microseconds.
And when TimeSpan is just a integer of seconds, the queries are easier to compose I think.