fix: Address regression introduced in #22853

[john-bodley]

SUMMARY

Per #22853 (comment), this PR addresses an issue introduced in #22853 where chart exploration from SQL Lab would instantiate TableColumn objects however there was no SqlaTable associated with said columns, which previously was a necessary requirement.

This PR augments the TableColumn class to include a Database object which is external to the ORM.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

CI and added some basic unit/integration tests.

Note there is very little unit/integration tests for this work beyond broad workflows. If people are accepting of this approach, I'll strive to add tests before merging, but I first thought there was merit to presenting this approach as a solution.

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

[john-bodley]

The SqlMetric class is still tightly bound to the SqlaTable.

[codecov]

Codecov Report

Merging #24121 (63ba034) into master (a3aacf2) will decrease coverage by 0.04%.
The diff coverage is 96.15%.

❗ Current head 63ba034 differs from pull request most recent head 60cb66a. Consider uploading reports for the commit 60cb66a to get more accurate results

@@            Coverage Diff             @@
##           master   #24121      +/-   ##
==========================================
- Coverage   69.05%   69.01%   -0.04%     
==========================================
  Files        1903     1903              
  Lines       74530    74522       -8     
  Branches     8105     8105              
==========================================
- Hits        51464    51434      -30     
- Misses      20955    20977      +22     
  Partials     2111     2111              

Flag	Coverage Δ
hive	53.83% <84.61%> (+0.03%)	⬆️
mysql	79.37% <96.15%> (+0.04%)	⬆️
postgres	79.44% <96.15%> (+0.04%)	⬆️
presto	?
python	83.26% <96.15%> (-0.07%)	⬇️
sqlite	77.96% <96.15%> (+0.04%)	⬆️
unit	54.25% <84.61%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset/models/sql_lab.py	77.91% <0.00%> (-0.66%)	⬇️
superset/connectors/sqla/models.py	89.72% <100.00%> (+0.09%)	⬆️
superset/initialization/__init__.py	91.38% <100.00%> (+0.02%)	⬆️
superset/models/core.py	89.89% <100.00%> (-0.07%)	⬇️

... and 2 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[john-bodley]

The SqlaTable.make_sqla_column_compatible method was moved to Database.make_sqla_column_compatible given that now the TableColumn.table variable can be None.

[john-bodley]

This is a rewrite of the previous logic using a list comprehension. The only addition is the database argument which is required given a SQL Lab Query object has no associated SqlaTable which is previously were/how the database was obtained.

[john-bodley]

A nice byproduct of this change is this previous logic can be removed given that the db_engine_spec is accessible if associated with a Query or SqlaTable.

[john-bodley]

See https://docs.sqlalchemy.org/en/13/orm/constructors.html. Note I'm not overly sure if super is necessary—it's not included in the example, but I gather it doesn't hurt.

[john-bodley]

Given that the database variable isn't part of the ORM I believe I'm correct in saying that it can only be defined via a keyword argument.

[hughhhh]

@john-bodley is there a follow up PR where'd you be using the database arg? also can you annotate this somehow to let people know this is going to be an ORM object vs some might assume it's an id

[john-bodley]

@hughhhh it's used in this PR here.

I've added a type annotation for clarity.

[hughhhh]

unknown

[john-bodley]

By design either self.table or self._database (but not both) will be defined and thus the database property will always be non-null.

[john-bodley]

@hughhhh I've addressed your comments.