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
Relative date filters don't work with custom date columns #33528
Comments
I can reproduce this on master today too. Bad SQL with custom column: SELECT
"source"."ID" AS "ID",
"source"."USER_ID" AS "USER_ID",
"source"."PRODUCT_ID" AS "PRODUCT_ID",
"source"."SUBTOTAL" AS "SUBTOTAL",
"source"."TAX" AS "TAX",
"source"."TOTAL" AS "TOTAL",
"source"."DISCOUNT" AS "DISCOUNT",
"source"."CREATED_AT" AS "CREATED_AT",
"source"."QUANTITY" AS "QUANTITY",
"source"."DateColumn" AS "DateColumn"
FROM (
SELECT
"PUBLIC"."ORDERS"."ID" AS "ID",
"PUBLIC"."ORDERS"."USER_ID" AS "USER_ID",
"PUBLIC"."ORDERS"."PRODUCT_ID" AS "PRODUCT_ID",
"PUBLIC"."ORDERS"."SUBTOTAL" AS "SUBTOTAL",
"PUBLIC"."ORDERS"."TAX" AS "TAX",
"PUBLIC"."ORDERS"."TOTAL" AS "TOTAL",
"PUBLIC"."ORDERS"."DISCOUNT" AS "DISCOUNT",
"PUBLIC"."ORDERS"."CREATED_AT" AS "CREATED_AT",
"PUBLIC"."ORDERS"."QUANTITY" AS "QUANTITY",
"PUBLIC"."ORDERS"."CREATED_AT" AS "DateColumn"
FROM "PUBLIC"."ORDERS") AS "source"
WHERE
"source"."DateColumn" = DATE_TRUNC('year', NOW())
LIMIT 2000 which looks plausible at a glance but doesn't return any data. The correct query (on WHERE (
"PUBLIC"."ORDERS"."CREATED_AT" >= DATE_TRUNC('year', NOW()))
AND
"PUBLIC"."ORDERS"."CREATED_AT" < DATE_TRUNC('year', DATEADD('year', CAST(1 AS long), CAST(NOW() AS datetime))) I guess the custom column's type isn't being correctly established. This may Just Work with MLv2-powered custom column types in the QP, or it might require a deliberate fix. (Maybe instead the resulting type of just a |
Fixes #33528 Turns out that `mbql/normalize` and `lib/normalize` behaved slightly different and `[:expression "abc" {...}]` refs would drop their opts in the former path. In order to properly query against binned datetimes it's important that expression ref does not lose its type or else the optimizer will not see that `time-interval` needs to convert to a `between` rather than an `=`.
* Fixes filters against datetime binned expressions Fixes #33528 Turns out that `mbql/normalize` and `lib/normalize` behaved slightly different and `[:expression "abc" {...}]` refs would drop their opts in the former path. In order to properly query against binned datetimes it's important that expression ref does not lose its type or else the optimizer will not see that `time-interval` needs to convert to a `between` rather than an `=`. * Fix test * Only keep specific keys on expression opts for these expression filters * Don't run checkin dataset on snowflake or athena
* Fixes filters against datetime binned expressions Fixes #33528 Turns out that `mbql/normalize` and `lib/normalize` behaved slightly different and `[:expression "abc" {...}]` refs would drop their opts in the former path. In order to properly query against binned datetimes it's important that expression ref does not lose its type or else the optimizer will not see that `time-interval` needs to convert to a `between` rather than an `=`. * Fix test * Only keep specific keys on expression opts for these expression filters * Don't run checkin dataset on snowflake or athena
* Fixes filters against datetime binned expressions Fixes #33528 Turns out that `mbql/normalize` and `lib/normalize` behaved slightly different and `[:expression "abc" {...}]` refs would drop their opts in the former path. In order to properly query against binned datetimes it's important that expression ref does not lose its type or else the optimizer will not see that `time-interval` needs to convert to a `between` rather than an `=`. * Fix test * Only keep specific keys on expression opts for these expression filters * Don't run checkin dataset on snowflake or athena Co-authored-by: Case Nelson <case@metabase.com>
Describe the bug
When using a relative date filter with a custom date column the query always returns "No results" despite data being present for the selected range.
To Reproduce
= [Created At]
, with name DateColumnActual result:
Expected result:
Created At
directly.Expected behavior
No response
Logs
No response
Information about your Metabase installation
Severity
P2
Additional context
No response
The text was updated successfully, but these errors were encountered: