Hi, just developing an app for internal use.
I created a Migration which used to work fine.
Unfortunately, when using the same migration on a new environment (docker nextcloud 25, fresh install for a new employee), only the changeSchema is triggered (db-tables are created), but the postSchemaChange seems not to be executed (i.e., the tables are empty).
if I enable the app, the changeSchema will be triggered, but not the postSchemaChange.
If I manually set the appversion in oc_appconfig to 0.0.1 and remove all entries regarding my app fom oc_migration, and then upgrade the app via occ upgrade, all migration steps (including postSchemaChange) are triggered.
So, I guess the migration itself is correct, but how can I enforce the postSchemaChange when enabling the app for the first time?
That’s the thing, even with LogLevel 1, there’s nothing in the logs.
For testing purposes, I installed a fresh new docker container (nc 25 apache), attached my app via filesystem to my git repo.
I used some unknown function in the postSchemaChange to trigger an error.
Enabling the app works “fine”, databases are created, no error triggered (i.e. postSchemaChange was not executed). I have every migration listet in oc_migrations and the desired app version (1.7.0.) in oc_appconfig.
after
delete from oc_migrations where app='if-cloudkiosk'; update oc_appconfig set configvalue="0.0.1" where appid='if-cloudkiosk' and configkey="installed_version";
nextcloud tells me, there’s an upgrade to the app. when executing this upgrade (browser or via occ), the error in the postSchemaChange occurres - if i remove the error, data will be created when performing this step.
So, I can trigger the desired migration manually, but as you said: that is not the expected behaviour.
@ChristophWurst I think I’ve seen a discussion a while ago somewhere already that the postSchemaChange is indeed not teiggered the very first time you enable an app…
Install repair steps are always executed. Move insert sample data to a repair step. You may use app config to store that the sample data was inserted to not do it twice and check it at the beginning of the repair step.
Hmm, maybe I’ll do some weird stuff in my migrations.
As considered by @kesselb , I moved the logic of filliing data to a repair step and inserted some $output->info() statements.
After that, I trashed all my docker containers and volumes to begin a fresh install.
I can see my app in the app-list as disabled. When enabling, all tables are generated, but still without data and no $output in the logs.
If I manually delete the migration steps from the database (as described above), and trigger some upgrade (web or occ), the repair steps are performed and the data is filled; this is the same behaviour as with the postSchemaChange() - I can see the $output - messages in the logs now. Therefore, I’m pretty sure that the Migration-script itself should be okay but somehow I messed up triggering something the correct way…
Just a question: Is the answer that my app is already in the filesystem and is not downloaded from the app-store?