Time for core and app upgrade with mimetype repair

[fossxplorer]

Updated both oC core, documents app to newer version and then ran:

$ ./occ upgrade --skip-migration-test -vvv
ownCloud or one of the apps require upgrade - only a limited number of commands are available
Repair step: Repair MySQL database engine
Repair step: Repair MySQL collation
Repair step: Repair SQLite autoincrement
Repair step: Repair duplicate entries in oc_lucene_status
Repair info: removing duplicate entries from lucene_status
Repair step: Repair config
Updated database
Disabled 3rd-party app: bookmarks
Disabled 3rd-party app: calendar
Disabled 3rd-party app: contacts
Disabled 3rd-party app: documents
Disabled 3rd-party app: files_odfviewer
Disabled 3rd-party app: galleryplus
Disabled 3rd-party app: mozilla_sync
Disabled 3rd-party app: music
Disabled 3rd-party app: news
Disabled 3rd-party app: notes
Repair step: Repair mime types <---- This took about 45 mins.
Repair step: Repair legacy storages
Repair step: Repair config
Repair step: Clear asset cache after upgrade
Repair info: Asset pipeline disabled -> nothing to do
Repair step: Generate ETags for file where no ETag is present.
Repair info: ETags have been fixed for 0 files/folders.
Repair step: Clean tags and favorites
Repair info: 0 tags for delete files have been removed.
Repair info: 0 tag entries for deleted tags have been removed.
Repair info: 0 tags with no entries have been removed.
Repair step: Drop old database tables
Repair step: Drop old background jobs
Repair step: Repair outdated OCS IDs
Update successful
Maintenance mode is kept active

After that i enabled tasks (which was updated to newer version) and ran
$ ./occ upgrade --skip-migration-test -vvv
ownCloud or one of the apps require upgrade - only a limited number of commands are available
Repair step: Repair MySQL database engine
Repair step: Repair MySQL collation
Repair step: Repair SQLite autoincrement
Repair step: Repair duplicate entries in oc_lucene_status
Repair info: removing duplicate entries from lucene_status
Repair step: Repair config
Updated database
Updating ... <-- why wasn't this done on the first upgrade run?
Updated to 0.10.1
Updating ...
Updated to 0.7.1
Repair step: Repair mime types <---- This took about 45 mins again!
Repair step: Repair legacy storages
Repair step: Repair config
Repair step: Clear asset cache after upgrade
Repair info: Asset pipeline disabled -> nothing to do
Repair step: Generate ETags for file where no ETag is present.
Repair info: ETags have been fixed for 0 files/folders.
Repair step: Clean tags and favorites
Repair info: 0 tags for delete files have been removed.
Repair info: 0 tag entries for deleted tags have been removed.
Repair info: 0 tags with no entries have been removed.
Repair step: Drop old database tables
Repair step: Drop old background jobs
Repair step: Repair outdated OCS IDs
Update successful
Maintenance mode is kept active

Is it necessary to have "Repair step: Repair mime types" run on both?
It's very time consuming when the oc_filecache is ~ 10mill records and this will certainly grow bigger with time which again increases the upgrade time.
The whole process took ~ 1.5H and i'm looking to reduce it wherever possible.

EDIT: this was done on current core stable8.1 (8.1.1)

[MorrisJobke]

@PVince81 Wasn't there a plan to split up app upgrades from core upgrades. Can we also move the (core) repair steps over to core only upgrades?

[PVince81]

The plan was only visually so far, see #16272

But it makes sense to also exclude the repair steps when doing app upgrades.

The mime types update should only run once though, there is a version check in it. Not sure why it's still trying to repair stuff.

[tflidd]

related to #18017 ?

[Yetangitu]

Certainly related, it is the same issue. As a quick'n'dirty temporary solution I added an option to the occ upgrade command to disable the mime repair tasks during upgrade, see
#18017 for more info.

[PVince81]

Closing as duplicate of #18017