[Bug]: Upgrade tries to change row format in MySQL, even if it's already correct

[nalt]

⚠️ This issue respects the following points: ⚠️

• [X] This is a bug, not a question or a configuration/webserver/proxy issue.
• [X] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• [X] I agree to follow Nextcloud's Code of Conduct.

Bug description

The upgrade command changes the row format of many tables to dynamic, even if it is already set to dynamic. The attempted change is repeated, apparently for each app that is upgraded. This takes almost an hour on larger installation, several minutes alone on oc_filecache.

Steps to reproduce

1. Check on oc_filecache for format: dynamic; options:row_format=DYNAMIC.
2. Run occ upgrade
3. Monitor MySQL status, you will see ALTER TABLE oc_filecache ROW_FORMAT = DYNAMIC

Expected behavior

No change of DB format if it is already correctly set

Installation method

Community Docker image

Nextcloud Server version

29

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

None

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 28 to 29)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• [ ] Default user-backend (database)
• [ ] LDAP/ Active Directory
• [ ] SSO - SAML
• [ ] Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[provokateurin]

From looking at the code it selects all tables (or tables with rows) that do not have the right collation set. Afterwards it only performs the ROW_FORMAT = DYNAMIC on those affected tables and the changes the collation. This means if you run into this over and over something with changing the collation isn't working successfully. Once the collation was changed for a table, it should never do it again, like you expected. Can you please share the logs (with loglevel=0 and debug=true) from when you run the upgrade command?