Open zhaorui2022 opened 11 months ago
@giftig Can you take a look?
@zhaorui2022 can you provide the presto version you're using? I only tested the change with trino, so it might be it's broken on certain older versions, back when Trino was still Presto, and especially since we're using different client libs for the two. The types we encounter here are a little complicated depending on exact context so we might need to either do some additional edge case handling or take a broader look at why we're getting such different types here.
This will probably be of interest to you as well @villebro
I believe it is 0.272-2AC4790
Also we found two other regressions on Presto:
View data missing prefix: SELECT
(day|hour_ts)?+.+FROM
, which eventually fails database table and table_extra APIs. (Edit: This seems an expected behavior due to Hive/Presto syntax incompatibilities)0.272 is significantly after presto and trino forked, the last common version was 0.215, in 2019. We've already started trying to divide the presto logic from the trino logic, and we're using a different client library now too, so this feels like a sign we might need to think about completely decoupling them; we'll likely introduce further regressions by fixing one and breaking the other, otherwise.
If this logic is currently broken on several presto versions we probably need to fork it, drop it from PrestoDbBaseSpec
and move it to the trino one instead, and either reinstate an old version to the PrestoDbSpec
or start from scratch (or probably a bit of both, start from an old version which seems to work and raise further issues from there).
It's unfortunate how much logic will end up forked / duplicated this way but it's probably unavoidable since presto/trino is forked itself, especially if we're seeing issues like timestamps having different expected precisions.
@zhaorui2022 it looks like there are some pending comments on your PR that need addressing to merge it and close out this issue. If you're able to get that one across the finish line, that would be amazing. Otherwise, if there are interested parties reading this thread that might want to pick up where the PR leaves off, that would also be fantastic!
This issue (and related PR) might be closed out as stale before long if nobody has interest in adopting them.
After we upgrade to 3.0.0, we have noticed that we can't add new Presto dataset (very simple table with just a bigint column still works, but others don't) due to unable to fetch table metadata. More specifically it is
api/v1/database/<int>/table/<table_name>/<schema>/
that's broken.How to reproduce the bug
Expected results
Show table columns as in previous version
Actual results
Shows an error
Screenshots
Environment
(please complete the following information):
superset version
3.0.0python --version
3.9node -v
N/AChecklist
Make sure to follow these steps before submitting your issue - thank you!
Additional context
Add any other context about the problem here.
Here is a sample stacktrace
I have temporarily reverted this part of the code back to what it was in 2.0.0, and that fixes the issue. But the commit introduced the change was supposed to fix another bug, so I am not sure if it is OK to just revert the commit. Sample commit.