__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!
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!