Issue 1:
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

Go to Chart Explore

Click on Edit dataset and change dataset

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: #11190

Recently closed bug: #11380

Issue 2:
I have checked the issue tracker for the same issue and I haven't found one similar

Superset version

0.19.0

Expected results

There are a large number of Issues asking about adding new Datasources / Connectors:

#381

#2790

#2468

#945

#241

#600

#245

Unfortunately, I can't find any examples of a working third party datasource / connector on Github and I think this is possibly because of the complexity and level of effort required to implement a BaseDatasource subclass with all the required methods. In particular, it needs to be able to report the schema and do filtering, grouping and aggregating.

Pandas has great import code, and I have seen Pandas proposed an a method for implementing a CSV connector - see #381 - read the CSV using Pandas and then output to sqlite and then connect to sqlite using the SQLA Datasource to create the slices.

This approach could be extended to other data formats that Pandas can read, e.g. Excel, HDF5, etc.

However, it is not ideal because the sqlite file will be potentially be out of date as soon as it is loaded.

I'd like to propose an altenative: a PandasDatasource that allows the user to specify the import method (read_csv, read_table, read_hdf, etc.) and a URL and which then queries the URL using the method to create a Dataframe. It reports the columns available and their types based on the dtypes for the Dataframe. And by default it allows grouping, filtering and aggregating using Pandas built in functionality.

I realize that this approach won't work for very large datasets that could overwhelm the memory of the server, but it would work for my use case and probably for many others. The results of the read, filter, group and aggregate would be cached anyway, so the large memory usage is potentially only temporary.

This would also make it very much easier for people working with larger datasets to create a custom connector to suit their purposes. For example, someone wanting to use BigQuery (see #945) could extend the PandasDatasource to use read_gbq and to pass the filter options through to BigQuery but still rely on Pandas to do grouping and aggregating. Given that starting point, someone else might come along later and add the additional code necessary to pass some group options through to BigQuery.

The point is that instead of having to write an entire Datasource and implement all methods, you could extend an existing one to scratch your particular itch, and over time as more itches get scratched we would end up with a much broader selection of datasources for Superset.