1

Closed

support .Date operator in SQL generation

description

NOTE: related to, but much smaller and more specific in scope, to work item 107 @ https://entityframework.codeplex.com/workitem/107

something linq-to-sql supports and EF does not is accessing the .Date property off of a DateTime value, with linq-to-sql (at least via LINQPad) converting it into CONVERT(DATE, [the_column_here])

The 'workaround' is to use EntityFunctions.TruncateTime, which appears to give the same functionality in terms of zeroing out the 'time' portion of the value.

Is this specific expression mapping (DateTime.Date -> EntityFunctions.TruncateTime) reasonable, but just fell out of scope for EF6 (but might be included in a version after EF6?). If it's reasonable for EF to make this change, what would a pull request that included it roughly look like and need to include?

Is there a method in EF6 to hook into the SQL generation such that doing this mapping in our own context is possible?

Thanks!
Closed Dec 13, 2016 at 6:55 PM by RoMiller
EF Team Triage: We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include:
  • It was a bug report that does not contain sufficient information for us to be able to reproduce it
  • It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it
  • It is a feature request that we are realistically not going to implement on the EF6.x code base
    Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). We will no longer be monitoring this issue tracker for comments, so please do not reply here.

comments

RoMiller wrote Aug 29, 2013 at 4:32 PM

EF Team Triage: We agree this would be good to support. Given where we are in the EF6 release we're putting this issue in the Future release to consider for upcoming releases.

jmanning wrote Aug 29, 2013 at 5:14 PM

Thanks, Rowan!

Any chance you could answer the other questions to help us out in terms of trying to do this ourselves in the mean time?
  • Is this specific expression mapping (DateTime.Date -> EntityFunctions.TruncateTime) reasonable, but just fell out of scope for EF6 (but might be included in a version after EF6?). If it's reasonable for EF to make this change, what would a pull request that included it roughly look like and need to include?
  • Is there a method in EF6 to hook into the SQL generation such that doing this mapping in our own context is possible?
Thanks again!