-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How does translation of comparison operators work for converted values? #33208
Comments
Duplicate of #10434 |
@ajcvickers , I know that issue. But how/why does it work now? |
I suspect it's just comparing the values in the same way it would with the default mapping. What does the SQL look like? |
@ajcvickers , yes, exactly as you say:
Then why does it fail for |
We specifically block those comparison operations for Sqlite (code), since on Sqlite DateTimeOffset (a commonly-used type) is by default value-converted to string, so it's a big pit of failure lots of people would fall into. But at the end of the day, the moment you go into value conversion, you have to be very careful with any operators/function calls you do. |
I've noticed =D Though I am a bit surprised that you decided to explicitly block some translations, yet by default EF just applies the same operators to converted values. I guess it's just more or less safe default as it's very unlikely conversion will change order relationship. I hope #10434 makes into EF 9 ;-) |
It's just about DateTimeOffset and Sqlite being a particular pit of failure, specifically because it's a default value conversion; the user doesn't opt in, and may have no idea that value conversion is even involved. If you explicitly configure value conversions, it makes a bit more sense that you're responsible (or hopefully at least considering) what happens with comparisons etc. |
|
Kind doesn't participate in comparisons so it's less of a problem. |
Btw, that's how I hacked custom comparison for DateTimeOffset (safe for me because it's always UTC):
|
If it's only UTC, why are you using DateTimeOffset in the first place (and always have |
Indeed, I switched to DateTime, but it was a nice experiment I learned a lot from. |
I used a DateTime to long conversion for Sqlite database:
I was expecting the query which compares two timestamps to fail, yet it works. But how? How does EF know that it should compare underlying longs? What if I decided to write negative values:
For example, for
DateTimeOffset
with conversion tostring
EF could not translate comparison to SQL.The text was updated successfully, but these errors were encountered: