fix: Handle python_date_format in ExploreMixin

[john-bodley]

SUMMARY

This PR fixes an issue introduced in #20938 however it didn't surface until #22853 which resulted in a somewhat bad correctness regression as the resulting generated SQL was incorrect when filtering the temporal column, i.e., rather than queries being generated of the form,

WHERE
    ds >= '2023-01-01'

they were being generated as:

WHERE
    ds >= '2023-01-01 00:00:00.000000'

which due to lexicographical ordering would wrongfully exclude any records where ds = 2023-01-01.

The TL;DR is #20938 replicated logic from the TableColumn class however it did not include the logic which adhered to the Python date/time format meaning that columns which weren't handled by the DB engine spec convert_dttm method were cast to an ISO 8601 formatted string adhering to the Y-%m-%d %H:%M:%S.%f format.

This PR adds the missing logic and removes the now unused (per #22853) TableColumn methods to help improve the code hygiene and readability—having two or more instances of the same function makes the code very difficult to grok. @hughhhh I would suggest you perform a second pass to make sure all the legacy logic which was ported to the ExploreMixin has been removed.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

Added unit tests which would have hopefully helped discovered the issue.

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]

Snap @betodealmeida this is the same logic as #24062. I've rebased my logic on your PR. I also added some unit tests as I realized these were missing.

[john-bodley]

In the TableColumn.dttm_sql_literal method this the db_extra is set. I gather it might have been set to None previously for connivence/ease.

[betodealmeida]

Snap @betodealmeida this is the same logic as #24062. I've rebased my logic on your PR. I also added some unit tests as I realized these were missing.

Sorry for not adding tests, this was blocking a release and we needed a quick fix.

[codecov]

Codecov Report

Merging #24068 (ce17c70) into master (6baa552) will increase coverage by 0.02%.
The diff coverage is 100.00%.

❗ Current head ce17c70 differs from pull request most recent head 3e36553. Consider uploading reports for the commit 3e36553 to get more accurate results

@@            Coverage Diff             @@
##           master   #24068      +/-   ##
==========================================
+ Coverage   68.22%   68.25%   +0.02%     
==========================================
  Files        1942     1942              
  Lines       75215    75192      -23     
  Branches     8145     8145              
==========================================
+ Hits        51318    51322       +4     
+ Misses      21812    21785      -27     
  Partials     2085     2085              

Flag	Coverage Δ
hive	53.19% <100.00%> (+0.02%)	⬆️
mysql	78.96% <100.00%> (+0.04%)	⬆️
postgres	79.03% <100.00%> (+0.04%)	⬆️
presto	53.12% <100.00%> (+0.02%)	⬆️
python	82.83% <100.00%> (+0.06%)	⬆️
sqlite	77.55% <100.00%> (+0.04%)	⬆️
unit	53.11% <100.00%> (+0.07%)	⬆️

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

Impacted Files	Coverage Δ
superset/connectors/sqla/models.py	89.77% <ø> (+2.53%)	⬆️
superset/models/helpers.py	69.73% <100.00%> (+0.61%)	⬆️

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

[michael-s-molina]

LGTM