twofactor_email v2 stores its settings in oc_preferences. My new v3 does, too, but slightly different. I use lib/Migration/Version….php to convert these settings and discard everything else.
My understanding of the Migration documentation is that the lib/Migration/Version….php shall stay untouched and thus be part of each subsequent app version – correct?
Furthermore, I expected it to be run just once. That’s not the case. Every app new version urges Nextcloud to do an upgrade – why? What must I change?
Once it ran, there should be an entry in oc_migrations. I see that this entry exists, so that’s not the culprit. Any ideas/tipps/links?
Exact. Once an app is installed in a vanilla NC, all migrations are enumerated that need to be carried out and are then applied in a sequence. Thus, the old migrations still need caring in the sense that they must still be executable in future NC versions. As the API is stable this should not cause trouble but just for completeness.
That is exactly the behavior as I understand it as well. That way, only migrations that are not yet applied are executed upon updating the app. This is implemented by the server.
If you have your app installed, you can check with occ migrations:status twofactor_mail about the current status of the migrations. What is the output there?
There is no command occ migrations:status, at least not in NC33.
There is however occ migrations:preview <VERSION>:
occ migrations:preview 32.0.5
Those apps are not supporting metadata yet and might initiate migrations on upgrade: impersonate, twofactor_email, twofactor_webauthn
The above command fetches the depicted metadata (of 32.0.5 in my example, the latest available version today).
repair-steps/pre-migration/step
* optional
* must contain a php class which is run before executing database migrations
* will not be used, only validated
(and similar texts for post-migration, live-migration, install and uninstall). But I don’t know what I need to do/add to “support metadata”. Any hints?
Have you set debug to true in your config.php file? The migration commands are only registered if you are in debug mode.
I suspect this is about migration metadata. I think this is just syntactic sugar for the admin to have a nice UI.
Though, I am not sure, if you should update the stuff in a migration or in a repair step. The repair step is there to, yeah, fix stuff. Let me quote the docs on migrations:
While in theory you can run any code in the pre- and post-steps, we recommend not to use actual php classes. With migrations you can update from any old version to any new version as long as the migration steps are retained. Since they are also used for installation, you should keep them anyway. But this also means when you change a php class which you use in your migration, the code may be executed on different database/file/code standings when being ran in an upgrade situation.
I feel, you are very close to put business logic related to version updates into the migration steps. That should be in a repair step as far as I understand. But maybe someone else has a different opinion.
