villebro commented on pull request #12552: URL: https://github.com/apache/superset/pull/12552#issuecomment-762912648
> I'm concerned that a db metadata with a large number of charts will require some migration risk to do this migration. > > Are we considering compatibility with the old syntax? I would prefer to be compatible with the original syntax. It's true that migrations are risky, and migrations should be avoided unless required. However, similar migrations have been done before, and I'm pretty confident we can write a migration that handles this correctly, as it's not that complex. At least we should be able to fix the vast majority of cases that would otherwise break with just a simple regex. The reason I personally prefer to either support the old format or create a migration is because: - For SIP-15 there was a deprecation warning that urged people to edit the chart and save it after checking that the new time range endpoints were ok. See e.g. https://github.com/apache/superset/pull/11417 . Point being we should try to avoid breaking existing charts unless it is unavoidable, especially post 1.0. - People tend to learn to learn to use shorthand whenever supported, and if `7 days` has historically worked equally well as `7 days ago`, I would suspect many charts out there will be using the old notation. This is probably also highly skewed - some users might not even notice, while other's might have always use the deprecated syntax, hence breaking lots of charts for certain users. If it's not difficult to implement, I would prefer to let old charts work, but force the user to update the time range if they edit the chart. But if that's difficult to implement or gets messy, I'd prefer to do a migration. ---------------------------------------------------------------- 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]
