Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: Removes the deprecated GENERIC_CHART_AXES feature flag #26372

Merged

Conversation

michael-s-molina
Copy link
Member

@michael-s-molina michael-s-molina commented Dec 27, 2023

SUMMARY

As part of the 4.0 approved initiatives, this PR removes the deprecated GENERIC_CHART_AXES feature flag.

The previous value of the feature flag was True and now the feature is permanently enabled.

TESTING INSTRUCTIONS

CI should be sufficient for merging this PR. We'll do a complete testing of 4.0 after all approved proposals are merged.

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

@michael-s-molina michael-s-molina added risk:breaking-change Issues or PRs that will introduce breaking changes hold! On hold v4.0 Label added by the release manager to track PRs to be included in the 4.0 branch labels Dec 27, 2023
Copy link

codecov bot commented Dec 27, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d8f7e2c) 67.29% compared to head (bdd6843) 69.65%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #26372      +/-   ##
==========================================
+ Coverage   67.29%   69.65%   +2.35%     
==========================================
  Files        1895     1895              
  Lines       74249    74179      -70     
  Branches     8257     8205      -52     
==========================================
+ Hits        49968    51671    +1703     
+ Misses      22206    20461    -1745     
+ Partials     2075     2047      -28     
Flag Coverage Δ
hive 53.81% <25.00%> (?)
mysql 77.97% <75.00%> (-0.01%) ⬇️
postgres 78.07% <75.00%> (-0.01%) ⬇️
presto 53.76% <25.00%> (?)
python 83.02% <100.00%> (+4.80%) ⬆️
sqlite 77.66% <75.00%> (-0.01%) ⬇️
unit 56.43% <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 michael-s-molina marked this pull request as ready for review January 5, 2024 18:52
@yousoph
Copy link
Member

yousoph commented Jan 5, 2024

We have some small improvements/fixes that we are planning to work on to help unblock some of our users from being able to enable the GENERIC_CHART_AXES flag. It would be appreciated if we could hold on merging this PR near the end of the breaking change window for Superset 4.0 so that we can get our changes completed first :) Thanks!!

@rusackas
Copy link
Member

Cypress Tests LGTM.... I can hit the code owner approval button, but might like to have a more holistic review/approval first.

@Vitor-Avila
Copy link
Contributor

Vitor-Avila commented Jan 12, 2024

hey @michael-s-molina one concern with the GENERIC_CHART_AXES removal, is that currently with the FF set to True the TIME GRAIN control for legacy charts is no longer visible:

image

Reported in #26474.

Existing charts will still work, but users are no longer able to change the time grain configuration if needed. Also, new legacy charts can't be properly created without this configuration.

Given we're not yet automatically migrating all legacy charts to ECharts, the full removal of the FF would introduce these issues to Organizations still using legacy charts.

I suspect we can fix this by setting the time_grain_sqla's visibility to return true in case we don't have an x_axis set in controls (in superset-frontend/packages/superset-ui-chart-controls/src/shared-controls/sharedControls.tsx). Something like this: https://github.com/apache/superset/compare/master...Vitor-Avila:superset:time-grain-legacy-charts?expand=1

Unsure if we would want to fix the bug first, and then make sure it's working properly before we move forward with this removal PR, or if you would actually prefer to include the fix here. I'm also further testing that branch to confirm if additional changes would be needed.

Let me know your thoughts! Happy to submit a PR from that branch.

@michael-s-molina
Copy link
Member Author

Hi @Vitor-Avila. You're correct, we should solve this in a specific PR and merge it before merging this PR. This problem was reported before and fixed for each chart that does not correctly handle both feature flag states. Check #26439 and #23865 for more context.

@villebro
Copy link
Member

I suggest we introduce two new shared time sections for legacy charts:

  • one that works with temporal charts (=has time grain)
  • one that works with non-temporal charts

Essentially these would be the same as genericTime and legacyRegularTime, but without the check for hasGenericChartAxes. These could then be used on legacy charts that don't want to support generic x-axis. These could then be removed once the last legacy chart has been removed.

@michael-s-molina
Copy link
Member Author

@villebro @Vitor-Avila Can any of you open a PR to fix this problem? Maybe we can even ask help from @sivasathyaseeelan. I have many things on my plate right now 😢

@Vitor-Avila
Copy link
Contributor

I feel like @villebro's suggestion seems more granular and scalable, but I'm still ramping up so I might not have the knowledge to implement it.

I thought this was mostly related with how we're checking if time_grain_sqla should be visible in the chart controls, but seems like it's also related with each visualization type configuration.

@villebro
Copy link
Member

@Vitor-Avila this should be a fairly straight forward change, and I can support you if you wish. But if you prefer I can open a PR and tag you for a review.

@sivasathyaseeelan
Copy link
Contributor

sivasathyaseeelan commented Jan 12, 2024

@villebro @Vitor-Avila Can any of you open a PR to fix this problem? Maybe we can even ask help from @sivasathyaseeelan. I have many things on my plate right now 😢

@michael-s-molina I would love to help you if you prefer

@Vitor-Avila
Copy link
Contributor

hey @villebro I was checking both the line and bar charts from nvd3 (the charts I reproduced the missing time grain issue), and I believe they both use the legacyTimeseriesTime:

export const legacyTimeseriesTime: ControlPanelSectionConfig = {
  ...baseTimeSection,
  controlSetRows: [
    ['granularity'],
    ['granularity_sqla'],
    ['time_grain_sqla'],
    ['time_range'],
  ],
};

I suspect the issue here is that the visibility settings for time_grain_sqla actually doesn't account for the scenario in which GENERIC_CHART_AXES is enabled but the chart doesn't have an X Axis (a legacy temporal chart):

const time_grain_sqla: SharedControlConfig<'SelectControl'> = {
  type: 'SelectControl',
  label: TIME_FILTER_LABELS.time_grain_sqla,

  ...

  visibility: ({ controls }) => {
    if (!hasGenericChartAxes) {
      return true;
    }

    const xAxis = controls?.x_axis;
    const xAxisValue = xAxis?.value;
    if (isAdhocColumn(xAxisValue)) {
      return true;
    }
    if (isPhysicalColumn(xAxisValue)) {
      return !!(xAxis?.options ?? []).find(
        (col: ColumnMeta) => col?.column_name === xAxisValue,
      )?.is_dttm;
    }
    return false;
  },
};

Is your suggestion to create these two new shared time sections so that legacy nvd3 charts also support X-Axis (categorical) axes? We can also sync tomorrow via Slack.

@michael-s-molina michael-s-molina removed the hold! On hold label Jan 16, 2024
name: 'time_grain_sqla',
config: {
...sharedControls.time_grain_sqla,
visibility: ({ controls }) => {
Copy link
Member

@geido geido Jan 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR. There are bunch of repeated logics between pivot table, chart table, and Box Plot that we could probably centralize at some point

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. I also noticed many repeated code between ECharts plugins. I'm delaying removing this repetition until after the migrations because I think we'll have a better overview of the common patterns.

@@ -401,7 +401,7 @@ export default function DateFilterLabel(props: DateFilterControlProps) {
ref={labelRef}
/>
</Tooltip>
{/* the zIndex value is from trying so that the Modal doesn't overlay the AdhocFilter when GENERIC_CHART_AXES is enabled */}
{/* the zIndex value is from trying so that the Modal doesn't overlay the AdhocFilter */}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated: Not sure I get the meaning of the sentence in this comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@geido The z-index value comes from trying, I'm not sure what's value is an appreciate value when I made this function.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the developer meant that the z-index value was set, after multiple tentative values, to make sure the modal doesn't overlay the filter.

Agree it's confusing 🤷🏼‍♂️

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem here is that we don't have a z-index registry which would automatically resolve this type of issue. Maybe we'll have one some day.

@michael-s-molina
Copy link
Member Author

@mistercrunch It seems the CI step called Label Migration PR is failing. Could you take a look?

@michael-s-molina michael-s-molina added the risk:db-migration PRs that require a DB migration label Jan 26, 2024
@michael-s-molina
Copy link
Member Author

/testenv up

Copy link
Contributor

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

@michael-s-molina michael-s-molina merged commit 8a2f7d3 into apache:master Jan 31, 2024
45 checks passed
Copy link
Contributor

Ephemeral environment shutdown and build artifacts deleted.

@rusackas
Copy link
Member

Woohoo!!!!

sfirke pushed a commit to sfirke/superset that referenced this pull request Mar 22, 2024
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 4.0.0 labels Apr 17, 2024
vinothkumar66 pushed a commit to vinothkumar66/superset that referenced this pull request Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels risk:breaking-change Issues or PRs that will introduce breaking changes risk:db-migration PRs that require a DB migration size/XXL v4.0 Label added by the release manager to track PRs to be included in the 4.0 branch 🚢 4.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants