louislam
commented
2 years ago You would still need to have a way to export and import the data from one kuma.db database to the next version. This would allow for a step upgrade process, even on older version of Uptime Kuma.
Sorry, but your solution will be a disaster. The script that moving data from one database to another database is hard to write. Also it will be super slow, because it keep writing/inserting data to the next database, even if the table is no change.
Patching the database by changing the schema directly is the most common way and easiest way as far as I know. At least I have seen other famous projects sush as Jellyfin, Wordpress are doing this.
You should check "Schema migration" in Google.
Close as not practical.
⚠️ Please verify that this feature request has NOT been suggested before.
🏷️ Feature Request Type
Other
🔖 Feature description
To fix or standardize the kuma.db file based on version to allow bulk import of sites via a script regardless of age of the existing program.
Problem: A base install via docker has a different database structure then a database which had a monitor added or a tag or a status page. This appears to be because Uptime Kuma relays on patching SQL files located in the db directory to bring the kuma.db data structure up to current version.
This causes bulk import of sites via scripts into the kuma.db file to be overly complex and forces the response of "It is not recommended" when someone asks if the kuma.db can be used for bulk import of sites via scripts.
✔️ Solution
Could you change the kuma.db files based on the available versions instead of SQL based patching files.
db/ kuma.db kuma-1.6.db kuma-1.7.db kuma-1.9.db kuma-1.13.db kuma-2.0.db
The kuma.db would have the complete database structure, so additional SQL based patching files are not needed and will not cause issues for later versions.
You would still need to have a way to export and import the data from one kuma.db database to the next version. This would allow for a step upgrade process, even on older version of Uptime Kuma.
If someone had version 1.6 and needed to upgrade to version 1.13. The upgrade process would simply run the upgrade-1.7, then upon completing, they can run the upgrade-1.9, and continue the process until the desired version has been reached.
If there is a concern about maintenance around the different versions of the database or transferring of data and you want to keep the current patch a base kuma.db file. See Alternatives.
❓ Alternatives
Can you clean up the .sql patching files so the upgrades or patches do not remove the existing data unless the column or table are being removed for the latest version.
Example - Adding maxredirects appear to be introduced in patch6.sql File: db/patch6.sql
This patch creates a temporary monitor table, then drops the monitor table and renames the temporary monitor table as the monitor table.
The drop of the monitor table removes all of the existing monitors. If this was needed for something in the past, ok. Can you go back and do a cleanup of the patch sql files to use an alter table to just add the missing column to monitor to be less destructive.
📝 Additional Context
If none of these suggestions will work, then can you provide a suggestion on what I can do in order to bulk import of sites via a script?