EBoisseauSierra commented on issue #14548: URL: https://github.com/apache/superset/issues/14548#issuecomment-840434745
You are right that mileages may vary, and sending a full `SELECT *` without any filter (other than [the “last resort” ones](https://github.com/apache/superset/blob/3f6bd1e4a4498de765ce0ebd4c7700f3bdbfe0bb/superset/config.py#L125-L126)) isn't ideal! (Plus my suggestions don't take backward compatibility into consideration) But as you mention, the “Last week” default isn't perfect, either because of too old data (cf. demo datasets)… or because — as in my particular `weather_forecast` scenario — we don't have _past_ data (I agree this isn't the most common, though). I quite like the idea of being able to define a meaningful filter (or representative subset) per dataset (plus a global default setting — defined in `config.py` — for the whole instance). It could be via a filter on the most representative timestamp column, or simply a `LIMIT`. However, I believe the main point I was trying to raise with §1 is that it's applying a filter _silently_ that affects the (new) user experience the most, as it's doing something they don't expect. Not applying any filter is only one approach to tackle this. Other approaches could be informing the user more pro-actively ; or (visibly) applying the filter by default, but waiting for the user to (go through all settings/parameters and) click on “Run” to execute the query. Shall we continue the discussion on #14473 (SIP-66) instead, where @junlincc has kindly cross-posted this issue? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
