Difference between revisions of "Friendica/upgrading"
(things I figured out during the 2017 upgrade, link to more extensive but highly specific SQL, and moved old update notes from main page) |
|||
| Line 1: | Line 1: | ||
==About== | ==About== | ||
| − | Documentation for upgrading Friendica's code and database schema | + | Database upgrade instructions are still difficult to find as of v2019-09: |
| + | * Update instructions on the [https://friendi.ca/2019/09/29/friendica-2019-09-released/ 2019-09 release page] say "please first update your Friendica instance to [v2018-09]". | ||
| + | * Update instructions on the [https://friendi.ca/2018/09/23/friendica-2018-09-released/ 2018-09 release page] say "First update to the 3.5.4 release", but do not link to instructions. | ||
| + | * The [https://friendi.ca/2017/10/16/friendica-3-5-4-release/ 3.5.4 release page] does not seem to have any update instructions. | ||
| + | |||
| + | Documentation for upgrading Friendica's code and database schema was minimal or at least difficult to find as of 3.5.2-dev. The following were applicable<ref name=woozle1 />: | ||
# Friendica automatically detects database issues and, when they are encountered, attempts to run a database upgrade. | # Friendica automatically detects database issues and, when they are encountered, attempts to run a database upgrade. | ||
# Before starting, it automatically puts the site into maintenance mode. | # Before starting, it automatically puts the site into maintenance mode. | ||
Revision as of 18:29, 12 October 2019
About
Database upgrade instructions are still difficult to find as of v2019-09:
- Update instructions on the 2019-09 release page say "please first update your Friendica instance to [v2018-09]".
- Update instructions on the 2018-09 release page say "First update to the 3.5.4 release", but do not link to instructions.
- The 3.5.4 release page does not seem to have any update instructions.
Documentation for upgrading Friendica's code and database schema was minimal or at least difficult to find as of 3.5.2-dev. The following were applicable[1]:
- Friendica automatically detects database issues and, when they are encountered, attempts to run a database upgrade.
- Before starting, it automatically puts the site into maintenance mode.
- If the upgrade completes successfully, it presumably takes the site back out of maintenance mode.
- If the upgrade does not complete successfully, there are no notifications to this effect; you have to check the logfile for errors.
- The current schema – much like Hubzilla's – has many table rows which try to set a default value for a DATETIME column, which (as of MySQL v5.7.17) may be disallowed by the server configuration.[2]
This means that the automated upgrade may fail, and the SQL to create or modify tables will have to be tweaked and executed manually. (Details may change from version to version, but my notes are here.)
Old Notes
Notes I took during the last upgrade seem to indicate that there was a way to explicitly request a db upgrade in the "admin area", but I haven't been able to find the admin area yet in the current version (which isn't currently working; hopefully when I get it working, it will appear and I can update this section).
Previous notes said:
The update process does not always go smoothly. If you see a message like this in the admin db_updates area:
Executing update_1141 failed. Check system logs.
...then what you need to do is view the update.php file, manually execute the given SQL (adjusting permissions or whatever is necessary until it has executed), and then click the "DB updates" link again to get the list of failed updates (in this case, it should show 1141) and then click on the link which says "Mark success (if update was manually applied)".
Footnotes
- ↑ 2017-04-08 Friendica migration follow-up post
- ↑ ibid. If the MySQL server is in strict mode and NO_ZERO_DATE is enabled, default values for DATETIME columns must be between '1970-01-01 00:00:01' and '2038-01-19 03:14:07' inclusive. "DEFAULT '0001-01-01 00:00:00'" is therefore disallowed, as are the many '0000-00-00 00:00:00' column values. (Found via Stack Overflow.)