Skip to content
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

Make it very clear when new versions have large schema updates #1151

Closed
mattab opened this issue Feb 11, 2010 · 5 comments
Closed

Make it very clear when new versions have large schema updates #1151

mattab opened this issue Feb 11, 2010 · 5 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc. Critical Indicates the severity of an issue is very critical and the issue has a very high priority.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Feb 11, 2010

We had issues in the past (in 0.5) when we released large schema upgrade causing time outs on some hosts, and we had to offer a lot of support in the forums.

I would like to propose a few steps to make this better in future releases (0.5.5 looks like it might contain such massive schema upgrade)

  1. Improve the messaging in the welcome update page and display a big red warning message when a large schema update will happen. This is the case whenever a large table (log_ or archive_) have new fields, new INDEXes, or various other bulk updates. We could have a flag/method in the update class that would be set to true when the update can potentially lead to such issues.

  2. We should also display the list of SQL queries that are going to be executed so that the user can execute them manually in case of error.

  3. Since 0.5 there is a feature that updates can be ran using the safer command line upgrade mechanism. This should also be highlighted.

@robocoder
Copy link
Contributor

(In [1844]) refs #1129, refs #1151 - refactoring to add getSql() to return array of SQL statements

@mattab
Copy link
Member Author

mattab commented Feb 12, 2010

Note: I created the ticket after reading the post mortem at: http://devzone.zend.com/article/11821-Yes-I-Crashed-the-Site

@robocoder
Copy link
Contributor

Brain dump. Not sure how practical this idea is...

see: http://www.php.net/manual/en/function.exec.php#86329

Idea is: (pseudocode)

if not php cli mode
    ignore_user_abort
    disable max_execution_time

    if exec() is not disabled
        exec('nohup php index.php >/dev/null 2>/dev/null &') // run the update in the background
        redirect to tmp/latest/progress.html // a static file that is overwritten by the updater
    else
        run updater // for each update, echo 'something' to the client and flush output buffers to (try) keep connection alive

else
    run updater // foreach update, write to progress.html

@mattab
Copy link
Member Author

mattab commented Mar 18, 2010

Anthon, I'm not going to test your pseudocode, it should like it might work, but generally if users have the exec() command, they might just want to run the command line updater I think.

let me know what you think of my improvements to the update welcome page; I hope this will help users get through large updates in the future

@mattab
Copy link
Member Author

mattab commented Mar 18, 2010

in [1941](again trac didn't pick up this commit, grr)

Fixes #1151
Clarifying update process for large piwik instances. outputs list of SQL queries that will be executed during updates.
Fixes language selector during update, which was only working after second refresh.

@mattab mattab added this to the Piwik 0.5.5 milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. Critical Indicates the severity of an issue is very critical and the issue has a very high priority.
Projects
None yet
Development

No branches or pull requests

2 participants