-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: DB conversion fails to migrate app_api tables and has issues with groupfolder and spreed #50667
Comments
As a workaround in the meanwhile, you could try |
DB conversion can't function for apps that aren't functioning / can't load. Does the same thing happen if you fix the Also, since you ran with Re: Happen to have the full output of the run? Sounds like our error handling could use some clean-up here in the convertor. |
hello, thanks for the solutions. Sorry I forgot to mention this was on a test setup and I have not lost any data, nor stuck with it.
The
No disabled app had its own custom table.
Yes, it was. Now all the data is inexistent in the new db. Also, the creation of tables had to be forced with app disable and enable.
Sorry, not now but I have the old db so it should be possible to simulate it again. I'll do it in some time if that is strictly required. |
That is not the reason here, though. The order the migrations are applied in, is wrong. Example for groupfolders:
The last migration that was run Available migrations sorted by prefixed number:
Available migrations sorted by date:
I don't know how the migration logic is supposed to work in NC, but either way, the way it works now can only be completely wrong. I hope it's only affecting the db:conversion progress and not the normal updating process, as that would be dangerous during normal upgrades, oof 🙈 Same for spreed, but I'm too lazy to format it all just to prove my point. Not sure which other apps are impacted as well, I mean at least they don't break the conversion process in this spectacular way, but it obviously doesn't mean it won't break later on. There is a reason we all are using schema migrations in all sorts of applications using databases, including a very specific order in which they have to be applied. |
According to the code for the Db\MigrationService,
LGTM that way. |
Bug description
Some apps fail to migrate from the old to the new db.
groupfolders
andspreed
(talk) throw errors about the column being inexistent. The columns were present in the old db and not present in the new db.app_api
is silently ignored and the tables are just listed as not to be migrated at the end.oc_context_chat_content_queue
is not migrated for no apparent reason, other tables from the app have been migrated.Steps to reproduce
php -d memory_limit=2048M occ db:convert-type --password postgres --all-apps pgsql postgres database-pgsql --port 5432 nextcloud
I have the old db data still.
Expected behavior
All database data is migrated successfully.
Nextcloud Server version
master
Operating system
None
PHP engine version
None
Web server
None
Database engine version
(to) postgresql version: Debian 17.0-1.pgdg120+1
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
The command output logs:
These errors were skipped by just removing the respective apps.
On a successful run, this was printed for the skipped tables.
oc_ex_*
tables and*_ex
tables belong to app_api and there was no error about it.There is nothing special about
oc_context_chat_content_queue
for it to be not migrated, apart from the fact that it is empty (did not have any rows).The text was updated successfully, but these errors were encountered: