You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 7, 2025. It is now read-only.
This eliminates an error we encountered with Hydrolix.
```
Q3006: Unspecified database error. clickhouse: query failed. err: code: 169, message: Key expression contains comparison between inconvertible types: DateTime64(3) and Float64 inside reqTimeSec >= 1727858503270
```
It's possible to compare dates and floats in Clickhouse from 2022 year,
but in 2021 it wasn't possible, and Hydrolix must use some earlier
version, so I created a solution which works in both scenarios
I move date parsing from Clickhouse to Quesma, removing usage of
Clickhouse's `parseDateTimeBestEffort()`. Now we parse date ourselves,
and use `toDateTime64()` to compare this date with date field (checked,
it works fine also for fields of basic `DateTime` type, not
`DateTime64`, even in Clickhouse 4 years ago). Elastic has like 50
different date formats available, so I doubt all of them are available
in Clickhouse or other databases, so it's a move in the right direction,
I guess.
After:
<img width="1728" alt="Screenshot 2024-10-06 at 17 15 22"
src="https://github.com/user-attachments/assets/952c6a9e-2a3e-43ce-85f5-fd19c1373018">
Timestamps are fine: there's `"gte": 1727858503270` in the request,
which is `Wed Oct 02 2024 08:41:43 GMT+0000`, so histogram starts fine
from `8:41:30`:
<img width="505" alt="Screenshot 2024-10-06 at 17 15 49"
src="https://github.com/user-attachments/assets/3d9acfb9-90c6-4341-b149-48c214e3d0d2">
---------
Co-authored-by: Jacek Migdal <[email protected]>
// Here we additionally verify that terms for `_tier` are **NOT** included in the SQL query
112
-
expectedQuery1:=`SELECT DISTINCT "client_name" FROM `+testTableName+` WHERE ("epoch_time">=parseDateTimeBestEffort('2024-02-27T12:25:00.000Z') AND "epoch_time"<=parseDateTimeBestEffort('2024-02-27T12:40:59.999Z')) LIMIT 13`
113
-
expectedQuery2:=`SELECT DISTINCT "client_name" FROM `+testTableName+` WHERE ("epoch_time"<=parseDateTimeBestEffort('2024-02-27T12:40:59.999Z') AND "epoch_time">=parseDateTimeBestEffort('2024-02-27T12:25:00.000Z')) LIMIT 13`
112
+
expectedQuery1:=`SELECT DISTINCT "client_name" FROM `+testTableName+` WHERE ("epoch_time">=fromUnixTimestamp64Milli(1709036700000) AND "epoch_time"<=fromUnixTimestamp64Milli(1709037659999)) LIMIT 13`
113
+
expectedQuery2:=`SELECT DISTINCT "client_name" FROM `+testTableName+` WHERE ("epoch_time">=fromUnixTimestamp64Milli(1709036700000) AND "epoch_time"<=fromUnixTimestamp64Milli(1709037659999)) LIMIT 13`
114
114
115
115
// Once in a while `AND` conditions could be swapped, so we match both cases
0 commit comments