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
Refactor updater and maybe installer #5985
Comments
in #6966 a bug was reported that may be caused by the fact that during Upgrades some calls to Instead of silently ignoring the |
Another issue (which is rather a "New feature" and should probably be in a separate issue) is that the upgrader should handle better the case when a plugin installation or upgrade triggers a large schema change, which times out in the browser. In some cases when the upgrade times out (or is it maybe in all cases?!), Piwik thinks that the plugin was successfully installed/upgraded although the schema changes were not fully done. This creates serious bugs such as matomo-org/plugin-MarketingCampaignsReporting#13 (comment) There is a workaround for this issue, which is to uninstall & re-install the plugin, and run the |
Just added another point to the list it would be very helpful if we were sometimes able to run SQL queries for updates in advance before updating the codebase. We would then also want to set a specific update script as "recorded" so it won't be executed again later. This works when the SQL query does not affect the product when using still an older codebase. This is something for advanced users only and we wouldn't make this probably much visible or at all. But we have to have the ability to run certain updates in advance and mark a certain update file as recorded. Also without getting the message "you are running an outdated codebase version of matomo with a newer DB version" |
What about instead of tying migrations to update versions, they are tied to a creation timestamp which serves as both ID & indication of order? Would have two benefits: one in that you could create a command to run/undo ('undo' in the future at least) any set of migrations by it's ID, and would mean if you created an Update, you don't have to also change the matomo version. |
Yes had something like this in mind too. We might even want to think about not mixing DB migrations with PHP migrations (eg config file etc) but that's a different topic and might not always be possible. |
In the past months we sometimes had troubles with extending the Updater / Installer.
config.ini.php
and then updating Piwik. Problem is when there are not only database changes but also local changes (eg modifyingpiwik.js
). Local changes would always need to be executed while database changes only might need to be executed when recorded component version in database is lower. Maybe we can separate those two use cases in the installer with different methods or so.core:update dry-run
As the platform grew we simply have more and more requirements to the updater but maybe also to the installer. With the knowledge we have today we could maybe improve the code of the updater and add some more features to make updates more flexible.
The text was updated successfully, but these errors were encountered: