Editing Datasource edits the name globally for all charts, not locally for the given chart

Currently when user edits datasource name of the Edit Dataset modal on Chart Explore, it looks like this change is saved globally for all charts / the original datasource gets renamed.

When user edits chart using Change Dataset option on Chart Explore, it only changes dataset locally for the chart.

Expected results

Is this behavior expected? Changing the dataset globally for all charts / actually renaming a dataset (which impacts all charts using this dataset) seems problematic to do on chart explore, when a user who doesn’t own the other charts can do this. It is really not clear to the user that it will change for all charts - especially because in the past, this only changed locally for the chart.

Actual results

Renames dataset, so it’s easy to break all charts!

Screenshots

I had two different chars using same dataset (broken). Wanted to change this for one of the charts. It got changed for both charts. (In this case it sounds great, but in most cases, it will unexpectedly break charts of other people).

Two different charts:

This modal changes dataset for both:

How to reproduce the bug

1. Go to Chart Explore
2. Click on Edit dataset and change dataset
3. See that all charts using the old dataset changed to new dataset

Environment

(please complete the following information):

• superset version: master

Checklist

Make sure these boxes are checked before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same issue and I haven’t found one similar.

Additional context

Recent discussion: https://github.com/apache/incubator-superset/issues/11190 Recently closed bug: https://github.com/apache/incubator-superset/issues/11380

[zuzana-vej]

#11781 solves our immediate need and that’s something we feel comfortable with, and I agree they are not exclusive, it’s step in the right direction either way. We don’t plan at this point to work on the next steps - but I am glad we were aligned this first step is in the right direction for everyone.

I get your point about user intents, and I think we should be very careful if we allow duplicating datasets, even though I see the point - that could be OK for small user base, but with 2500 WAUs and hundreds of data sets, this will cause clutter - many duplicate datasets, resulting in any migrations being possibly much harder, possibly scaling issues, users getting confused if each of their charts uses different dataset they duplicated earlier and forgot, and more. So would love to be part future discussions on this topic if this is to be considered.

[benceorlai]

I think PR #11781 is a very good stepping stone to start solving this problem. What Stephen proposed are options to go further with the solution.

The core problem in my opinion is that: the user in Explore wants to modify the dataset to fit their needs for a modified or new visualization. I think the intent can be one of two intents: make permanent changes to the Dataset OR make some ad-hoc changes to test a new visualization. Making the edits harder does not seem to solve the actual user need, it just makes it harder to achieve. The actual solution can include the option to do a “Save as” on the dataset, because that allows the user to make the breaking changes, get the dataset they want AND avoid impacting other users.

Hence our proposal for a duplicate dataset flow (Option 1): “Do you need to test some ad hoc changes in the Dataset?” - “Do it on a personal copy, without the risk of affecting others”

I don’t think our proposal is mutually exclusive with Grace’s PR #11781, rather it further extends on it, while offers a viable non-breaking alternative flow.

I am aware this solution needs more work and we will be glad to consider it for our roadmap if engineering resources are a concern.