fix: revert fix(presto preview): re-enable schema previsualization for Trino/Presto table/schemas"

[john-bodley]

SUMMARY

This PR reverts #26782 which was merged last week. Regrettably said logic seems to be problematic and throws a error:

Traceback (most recent call last):
  ...
  File "superset/db_engine_specs/presto.py", line 512, in where_latest_partition
    if col_type_class := getattr(types, col_type_name, None):
TypeError: getattr(): attribute name must be string

given that col_type_name isn't a string but rather a SQLAlchemy SQL type representing the column type—as denoted by the column_type_by_name mapping.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

CI.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

cc: @brouberol

[brouberol]

Feel free to revert, obviously! However I believe that the initial state was buggy in itself (at least that's what we experienced). If you can, could you add the values of the following variables?

• col_names
• values
• column_type_by_name

If somehow something changed in the types exposed by the col_names and values variable, we could adapt (or even remove) the logic I added. My only doubt is whether reverting will get us back to a working state, or into the initial buggy state.

[john-bodley]

@brouberol during testing I saw values of the form (santized):

• col_names: ['ds']
• values: ('2024-05-20',)
• column_type_by_name {'ds': VARCHAR(), ...}

The TL;DR is—per the well named column_type_by_name mapping—the values are SQLAlchemy types as opposed to str.