feat: Adds option to disable drill to detail per database

[michael-s-molina]

SUMMARY

This PR adds an option to disable the drill to detail feature per database. This is useful for databases that don't support atomic-level queries or contain large amounts of data not suitable for this type of operation.

During the planning phase of 4.0, the proposal to deprecate the DRILL_TO_DETAIL feature flag was rejected for the same reasons this PR is introducing this configuration. The hope is that with this new feature, we can deprecate the feature flag in the next major release. @mattitoo

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Screen.Recording.2024-03-15.at.15.36.00.mov

TESTING INSTRUCTIONS

Check that the drill to detail feature can be disabled/enabled for a specific database.

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

[codecov]

Codecov Report

Attention: Patch coverage is 87.50000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 69.82%. Comparing base (f274c47) to head (d596899).
Report is 1393 commits behind head on master.

Files with missing lines	Patch %	Lines
...ponents/Chart/DrillDetail/DrillDetailMenuItems.tsx	84.21%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #27536      +/-   ##
==========================================
+ Coverage   67.46%   69.82%   +2.35%     
==========================================
  Files        1910     1910              
  Lines       74802    74812      +10     
  Branches     8345     8346       +1     
==========================================
+ Hits        50467    52234    +1767     
+ Misses      22284    20526    -1758     
- Partials     2051     2052       +1     

Flag	Coverage Δ
hive	48.99% <100.00%> (?)
javascript	57.39% <84.21%> (-0.01%)	⬇️
mysql	78.00% <100.00%> (-0.03%)	⬇️
postgres	78.14% <100.00%> (+<0.01%)	⬆️
presto	53.72% <100.00%> (?)
python	83.15% <100.00%> (+4.87%)	⬆️
sqlite	77.57% <100.00%> (+<0.01%)	⬆️
unit	56.68% <100.00%> (?)

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[michael-s-molina]

/testenv up

[github-actions]

@michael-s-molina Ephemeral environment spinning up at http://52.36.126.48:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

[john-bodley]

Thanks @michael-s-molina for adding this option. My only question relates to:

This PR adds an option to disable the drill to detail feature per database.

and whether this should be configured at the database or dataset level. I'm not sure if it's typical that non-viable use cases are typically engine specific or dataset specific, though—as you point out—access to the underly records is likely database specific.

Note the drill-to-detail feature doesn't strictly require atomic level data, i.e., it works with Druid where the underlying data is typically rolled-up, however users are only exposed to the (partially) pre-aggregated records.

[michael-s-molina]

Note the drill-to-detail feature doesn't strictly require atomic level data, i.e., it works with Druid where the underlying data is typically rolled-up, however users are only exposed to the (partially) pre-aggregated records.

I'm thinking more about databases that only contain aggregated data but not the atomic data that was used to compute the aggregations. In those cases, drill to detail won't make sense.

[michael-s-molina]

and whether this should be configured at the database or dataset level. I'm not sure if it's typical that non-viable use cases are typically engine specific or dataset specific, though—as you point out—access to the underly records is likely database specific.

I think they are not mutually exclusive. We could have the same setting at the dataset level. I decided to start at the database level because I think the more common scenario is to have databases with no atomic data or large amounts of data. We may also have many virtual datasets, making the configuration harder.

[github-actions]

Ephemeral environment shutdown and build artifacts deleted.