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

Time shift difference #5177

Merged
merged 17 commits into from
Jul 16, 2018
Merged

Time shift difference #5177

merged 17 commits into from
Jul 16, 2018

Conversation

betodealmeida
Copy link
Member

I added a new control to allow comparing comparing the main time series with time shifts. In addition to showing the time shift as individual lines, it's now possible to compute absolute and relative differences.

Current behavior, will be the default option in the selector ("individual lines"):

screen shot 2018-06-11 at 4 03 21 pm

Absolute difference:

screen shot 2018-06-11 at 4 03 28 pm

Relative difference, computed as (main - time_shift) / time_shift (for a "1 week" shift" this means that 100 means the value today is double the value last week, and -50 means that the value today is half of what it was last week):

screen shot 2018-06-11 at 4 03 37 pm

@mistercrunch
Copy link
Member

I think this is effectively the same as a superior Period Ratio isn't it? If so we should db migrate to translate the slices.

I know one difference in the backend is that Period Ratio runs 2 queries and merges them. So I could look at the past 28 days and compare with last year's same period. I'm not sure if Time Shift can do that or it would query/show more than 28 days (which may be ok). What do you think?

@codecov-io
Copy link

codecov-io commented Jun 11, 2018

Codecov Report

Merging #5177 into master will decrease coverage by 15.57%.
The diff coverage is 39.53%.

Impacted file tree graph

@@             Coverage Diff             @@
##           master    #5177       +/-   ##
===========================================
- Coverage   76.78%   61.21%   -15.58%     
===========================================
  Files          44      373      +329     
  Lines        8944    23709    +14765     
  Branches        0     2750     +2750     
===========================================
+ Hits         6868    14513     +7645     
- Misses       2076     9181     +7105     
- Partials        0       15       +15
Impacted Files Coverage Δ
superset/assets/src/explore/controls.jsx 46.96% <0%> (ø)
superset/assets/src/visualizations/nvd3_vis.js 8.14% <0%> (ø)
superset/assets/src/explore/visTypes.jsx 57.14% <100%> (ø)
superset/viz.py 77.34% <27.27%> (-0.51%) ⬇️
superset/assets/src/SqlLab/actions.js 71.25% <50%> (ø)
superset/assets/src/explore/store.js 23.07% <50%> (ø)
.../src/explore/components/ControlPanelsContainer.jsx 88.31% <72.72%> (ø)
superset/db_engine_specs.py 54.07% <0%> (-0.23%) ⬇️
...et/assets/src/dashboard/reducers/dashboardState.js 94.59% <0%> (ø)
superset/assets/src/components/ModalTrigger.jsx 97.05% <0%> (ø)
... and 328 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c445ef8...f0a72de. Read the comment docs.

@betodealmeida
Copy link
Member Author

I think this is effectively the same as a superior Period Ratio isn't it? If so we should db migrate to translate the slices.

I'm not familiar with the period ratio, and it doesn't seem to map 1:1 to the comparison types. Should I create a migration script only for those cases that can be mapped?

I know one difference in the backend is that Period Ratio runs 2 queries and merges them. So I could look at the past 28 days and compare with last year's same period. I'm not sure if Time Shift can do that or it would query/show more than 28 days (which may be ok). What do you think?

How I would that with the period ratio? For time shift you would select the last 28 days and then use "1 year" as the time shift.

@vylc
Copy link

vylc commented Jun 12, 2018

Some updates to the AA section to improve usability
screen shot 2018-06-12 at 3 33 09 pm

@betodealmeida
Copy link
Member Author

screen shot 2018-06-14 at 2 14 04 pm

@@ -1562,24 +1562,6 @@ export const controls = {
description: t('Compute the contribution to the total'),
},

num_period_compare: {
Copy link
Member

Choose a reason for hiding this comment

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

If deprecating num_period_compare and period_ratio_type, do we need a db migration for existing charts that have been saved using that feature?

@mistercrunch
Copy link
Member

LGTM apart from the db migration needed comment.

@betodealmeida
Copy link
Member Author

@mistercrunch, I've added a migration script. Here's a dashboard that was saved before the migration:

screen shot 2018-07-06 at 6 45 00 pm

Note that:

  • granularity is month;
  • num_period_compare is 24 (months);
  • period_ratio_type is "growth" (ie, new/old - 1).

After the migration:

screen shot 2018-07-06 at 8 04 02 pm

Now:

  • time_compare is "2 years" (though it doesn't show in the dropdown since it's free form);
  • comparison_type is "percentage" (same as "growth", just renamed).

@mistercrunch
Copy link
Member

LGTM

@mistercrunch mistercrunch merged commit 7b4e6c7 into apache:master Jul 16, 2018
@williaster
Copy link
Contributor

williaster commented Jul 17, 2018

@betodealmeida this broke my local build, the db migration fails. I think you need to check if granularity is defined.

image

@timifasubaa
Copy link
Contributor

Same here

@@ -68,6 +68,7 @@
"geojson-extent": "^0.3.2",
"geolib": "^2.0.24",
"immutable": "^3.8.2",
"is-react": "^1.1.1",
Copy link
Contributor

Choose a reason for hiding this comment

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

@betodealmeida @mistercrunch was it necessary to add this dependency for functionality that is already provided by React natively?

from the source:
React.isValidElement(typeElement)

Copy link
Contributor

Choose a reason for hiding this comment

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

FYI this added react 16 as a direct dependency (not a peer dependency), which means we have 2 versions of react floating around. it'd be great to get rid of this.

Copy link
Member Author

Choose a reason for hiding this comment

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

Let me take a look.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed in #5478.

timifasubaa pushed a commit to airbnb/superset-fork that referenced this pull request Jul 25, 2018
* Allow different comparisons when using time shift

* Remove test code

* Remove lead/trail NaN and improve code

* Add headers/subheader

* Update yarn

* Migration script

* Fix migration

* Small fixes

* Trigger tests

* Fix lint

* Fix javascript
graceguo-supercat pushed a commit to graceguo-supercat/superset that referenced this pull request Jul 26, 2018
* Allow different comparisons when using time shift

* Remove test code

* Remove lead/trail NaN and improve code

* Add headers/subheader

* Update yarn

* Migration script

* Fix migration

* Small fixes

* Trigger tests

* Fix lint

* Fix javascript

(cherry picked from commit 7b4e6c7)
self.to_series(
diff, classed='time-shift-{}'.format(i), title_suffix=label))

return sorted(chart_data, key=lambda x: tuple(x['key']))
Copy link
Contributor

Choose a reason for hiding this comment

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

@betodealmeida we've been seeing issues with the stacked line chart where the lines are not sorted correctly. The stacked chart has sort_series set to true, and that sorting is done before this gets called, so I think this sorting is causing the issue. Is it necessary to sort here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Taking a look at this.

Copy link
Member Author

Choose a reason for hiding this comment

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

IIRC this is needed in order to color the groups in different timeshifts with the same color (eg, make sure "boys" is red in the main series as well as all offsets).

wenchma pushed a commit to wenchma/incubator-superset that referenced this pull request Nov 16, 2018
* Allow different comparisons when using time shift

* Remove test code

* Remove lead/trail NaN and improve code

* Add headers/subheader

* Update yarn

* Migration script

* Fix migration

* Small fixes

* Trigger tests

* Fix lint

* Fix javascript
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 0.28.0 labels Feb 27, 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 🚢 0.28.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants