Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Casting integer to Datatime via Table Metadata makes column unusable #41122

Closed
Tony-metabase opened this issue Apr 8, 2024 · 1 comment · Fixed by #41147
Closed

Casting integer to Datatime via Table Metadata makes column unusable #41122

Tony-metabase opened this issue Apr 8, 2024 · 1 comment · Fixed by #41147
Assignees
@bshepherdson
Labels
.Escalation .metabase-lib Label for tracking all issues related to the shared CLJC metabase-lib Priority:P1 Security holes w/o exploit, crashing, setup/upgrade, login, broken common features, correctness .Regression Bugs that were previously fixed and/or bugs unintentionally shipped with new features. .Team/QueryProcessor :hammer_and_wrench: Type:Bug Product defects
Milestone
0.49.4

Comments

@Tony-metabase
Copy link
Contributor

Describe the bug

Casting integer to Datatime via Table Metadata makes column unusable ... The lack of logs or error in console makes this absolutely insane to debug

To Reproduce

  1. Go to Admin -> Table Metadata -> Sample DB -> Orders -> Set Product_ID to Creation Date
image
  1. Then edit setting and cast it to DateTime
image
  1. Go to the orders table via the GUI and notice that the product ID turned into a Date (I know it doesn't make sense in this case but it's the easiest replication path)
image
  1. Now try to filter on the Product_ID
Screen.Recording.2024-04-08.at.14.05.29.mov

Expected behavior

The filtering needs to work and even though it kind of works it's not visible in the GUI

Logs

None

Information about your Metabase installation

Works on 48 but breaks on any 49 release

Severity

This will break the GUI functionality for anyone casting epoch times to Date

Additional context

Left the needs triage since i have no clue if its a backend or frontend issue since there are no logs anywhere
@Tony-metabase Tony-metabase added Type:Bug Product defects Priority:P1 Security holes w/o exploit, crashing, setup/upgrade, login, broken common features, correctness .Needs Triage .Escalation labels Apr 8, 2024
@bshepherdson bshepherdson added .metabase-lib Label for tracking all issues related to the shared CLJC metabase-lib .Team/QueryProcessor :hammer_and_wrench: and removed .Needs Triage labels Apr 8, 2024
@bshepherdson
Copy link
Contributor

This is very likely an MLv2 issue, rejecting the badly typed filter.

I'll look into it.

@cbalusek cbalusek added the .Regression Bugs that were previously fixed and/or bugs unintentionally shipped with new features. label Apr 8, 2024
bshepherdson added a commit that referenced this issue Apr 8, 2024
@bshepherdson
[MBQL lib] Don't enforce expression types when converting from legacy
b7d0d2e 
These type checks are useful when constructing clauses with full MLv2
metadata available, but when converting from legacy the `:field` refs
have only `:base-type`.

If a column has its metadata overridden to eg. coerce a string or
integer into a date, its `:base-type` will remain `:type/Integer` or
`:type/Text` and the `:effective-type` will be `:type/Date` etc.

This change skips the type check while converting from legacy, and
while checking `can-run`. Eventually this should be replaced with
tracking `:effective-type` on refs or using real metdata, instead of
relying on the `:base-type` only.

Fixes #41122.
@bshepherdson bshepherdson mentioned this issue Apr 8, 2024
Merged
bshepherdson added a commit that referenced this issue Apr 9, 2024
@bshepherdson
[MBQL lib] Don't enforce expression types when converting from legacy
5e10e4d 
These type checks are useful when constructing clauses with full MLv2
metadata available, but when converting from legacy the `:field` refs
have only `:base-type`.

If a column has its metadata overridden to eg. coerce a string or
integer into a date, its `:base-type` will remain `:type/Integer` or
`:type/Text` and the `:effective-type` will be `:type/Date` etc.

This change skips the type check while converting from legacy, and
while checking `can-run`. Eventually this should be replaced with
tracking `:effective-type` on refs or using real metdata, instead of
relying on the `:base-type` only.

Fixes #41122.
bshepherdson added a commit that referenced this issue Apr 9, 2024
@bshepherdson
[MBQL lib] Don't enforce expression types when converting from legacy
771f984 
These type checks are useful when constructing clauses with full MLv2
metadata available, but when converting from legacy the `:field` refs
have only `:base-type`.

If a column has its metadata overridden to eg. coerce a string or
integer into a date, its `:base-type` will remain `:type/Integer` or
`:type/Text` and the `:effective-type` will be `:type/Date` etc.

This change skips the type check while converting from legacy, and
while checking `can-run`. Eventually this should be replaced with
tracking `:effective-type` on refs or using real metdata, instead of
relying on the `:base-type` only.

Fixes #41122.
bshepherdson added a commit that referenced this issue Apr 9, 2024
@bshepherdson
[MBQL lib] Don't enforce expression types when converting from legacy (…
15b90a0 
…#41147)

These type checks are useful when constructing clauses with full MLv2
metadata available, but when converting from legacy the `:field` refs
have only `:base-type`.

If a column has its metadata overridden to eg. coerce a string or
integer into a date, its `:base-type` will remain `:type/Integer` or
`:type/Text` and the `:effective-type` will be `:type/Date` etc.

This change skips the type check while converting from legacy, and
while checking `can-run`. Eventually this should be replaced with
tracking `:effective-type` on refs or using real metdata, instead of
relying on the `:base-type` only.

Fixes #41122.
bshepherdson added a commit that referenced this issue Apr 9, 2024
@bshepherdson
[MBQL lib] Don't enforce expression types when converting from legacy (…
2c72f1d 
…#41147)

These type checks are useful when constructing clauses with full MLv2
metadata available, but when converting from legacy the `:field` refs
have only `:base-type`.

If a column has its metadata overridden to eg. coerce a string or
integer into a date, its `:base-type` will remain `:type/Integer` or
`:type/Text` and the `:effective-type` will be `:type/Date` etc.

This change skips the type check while converting from legacy, and
while checking `can-run`. Eventually this should be replaced with
tracking `:effective-type` on refs or using real metdata, instead of
relying on the `:base-type` only.

Fixes #41122.
darksciencebase pushed a commit that referenced this issue Apr 10, 2024
@metabase-bot @bshepherdson
[MBQL lib] Don't enforce expression types when converting from legacy (…
62721d3 
…#41147) (#41203)

These type checks are useful when constructing clauses with full MLv2
metadata available, but when converting from legacy the `:field` refs
have only `:base-type`.

If a column has its metadata overridden to eg. coerce a string or
integer into a date, its `:base-type` will remain `:type/Integer` or
`:type/Text` and the `:effective-type` will be `:type/Date` etc.

This change skips the type check while converting from legacy, and
while checking `can-run`. Eventually this should be replaced with
tracking `:effective-type` on refs or using real metdata, instead of
relying on the `:base-type` only.

Fixes #41122.

Co-authored-by: Braden Shepherdson <braden@metabase.com>
@bshepherdson bshepherdson added this to the 0.49.4 milestone Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bshepherdson bshepherdson

Labels
.Escalation .metabase-lib Label for tracking all issues related to the shared CLJC metabase-lib Priority:P1 Security holes w/o exploit, crashing, setup/upgrade, login, broken common features, correctness .Regression Bugs that were previously fixed and/or bugs unintentionally shipped with new features. .Team/QueryProcessor :hammer_and_wrench: Type:Bug Product defects
Projects
None yet
Milestone
0.49.4
Development

Successfully merging a pull request may close this issue.

[MBQL lib] Don't enforce expression types when converting from legacy metabase/metabase
3 participants
@bshepherdson @cbalusek @Tony-metabase