-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
queries with strings that look like dates end up with date types, not string types #6727
Comments
@jsternberg @benbjohnson Another probable query bug. This one I'm pretty sure isn't operator error, but if so I welcome the education! |
Thanks for support @beckettsean Another observation: I tried appending date like fields with additional information like "1999-01-01" was appended with "1999-01-01a" still the behaviour is erroneous. This also happens for long format like "1999-01-01 12:34:00". |
This is a result of our over-eager parser trying to assign a date/time type before it has the context of where that value is in the query... I hacked a quick delayed-evaluation that allows strings to be used, and then parsed as timestamps only if there are compared against
It probably broke another part of the system, but I'll try to get it cleaned up for a PR |
The current code would compare every string literal it crossed and tried to coerce them to time literals if the _looked_ like date/time strings. The only time the TimeLiteral was used is when comparing to the the 'time' value in a where clause. This change moves the string parsing code until we attempt to compare 'time' to a string, at which point we know we need/want a TimeLiteral, and not just an ordinary string. Fixes #6727
The current code would compare every string literal it crossed and tried to coerce them to time literals if the _looked_ like date/time strings. The only time the TimeLiteral was used is when comparing to the the 'time' value in a where clause. This change moves the string parsing code until we attempt to compare 'time' to a string, at which point we know we need/want a TimeLiteral, and not just an ordinary string. Fixes #6727
Bug report
System info: [Include InfluxDB version, operating system name, and other relevant details]
InfluxDB 0.13.0 from package on Ubuntu 14.04
The query engine interprets date-like strings in the WHERE clause into dates, even when they should stay strings. This renders string comparison operators non-functional and leads to confusing query returns.
Test data
So far, everything is behaving as expected, but when we use a string that looks like a date, we end up with spurious matches we didn't expect:
Submitting a date-like string that won't parse as a date shows the error very clearly:
Even if the actual field values don't look like dates, if the query filter string does, it shows the behavior:
This is not a CLI bug, it's in the query engine:
The text was updated successfully, but these errors were encountered: