NHibernate.QueryException : could not resolve property: LocalDateTime
Description
Trying to use DateTimeOffset.LocalDateTime on a property of type DateTimeOffset in a LINQ projection yields the exception: NHibernate.QueryException : could not resolve property: LocalDateTime of: <the entity type>
It would be difficult to execute this in SQL Server before SQL Server 2016, when timezone information was added. However, in a select clause, it could conceivably be executed locally in the CLR during hydration.
Probably affects various other properties too.
Environment
None
Activity
Show:
Alex Zaytsev April 27, 2017 at 9:54 PM
Edited
Methods are considered to be client side (.NET) unless marked as server side (DB) Properties are considered to be server side (DB) only. Also, properties are considered to be mapped to a column/formula unless generator specified.
I think we need to allow users to mark properties to be executed as client side as a short term solution. In a long term LINQ provider shall analyze properties and decide how to handle them based on mapping.
can you check if the workaround with the following extension method will work?
Frédéric Delaporte April 27, 2017 at 5:18 PM
That sounds as quite a novelty. CLR execution before querying is usual, but after, I do not think it is. We need to devise where and how to handle that for having it play nicely with caching while preferably not impacting others querying API.
Or maybe only support the feature on servers handling timezone.
Handling fallback to CLR may additionally call for an option allowing evaluating in CLR even if server handles it: the SQL server may use another timezone than the application. Then it could create inconsistent behaviors between where conditions on `LocalDateTime` and returned values by select.
Trying to use DateTimeOffset.LocalDateTime on a property of type DateTimeOffset in a LINQ projection yields the exception:
NHibernate.QueryException : could not resolve property: LocalDateTime of: <the entity type>
It would be difficult to execute this in SQL Server before SQL Server 2016, when timezone information was added. However, in a select clause, it could conceivably be executed locally in the CLR during hydration.
Probably affects various other properties too.