Documentation for upgrading Friendica's code and database schema is minimal or at least difficult to find. As of 3.5.2-dev, the following was applicable:
- 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.
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.)
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)".
- 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.)