Hi @robin, today I upgraded my test instance to 8.0, which is really easy by the way as I'm using docker. But while watching the upgrade logs, I was wondering, how does OneDev's migration style scales? How big is this instance's Database and what is the largest one you know of? I'm asking because it is not that common for database migrations to be done this way (exporting and importing the whole database to/from XML). A pro of doing it this way is that it is very easy to migrate to different databases, but I guess it would be way more performant to do traditional alter tables for regular migrations.
Robin Shen commented 1 year ago
Good observation! OneDev migrates data this way in order to support different databases easily. Also writing sql to migrate data is very limited, for instance, you can not migrate serialized data (storing serialized binary data in database makes many logic a lot easier), and you can not do very complex data migrations.
The drawback is also very obvious, it will be slower. To test how it performs on non-trivial dataset, I populated an instance on my laptop with below metrics:
issues: 151147
comments: 517068
fields: 666102
The upgrade completes within 10min, which is acceptable I think.
On the other hand, if this becomes a real issue some day in future, I can switch to upgrade with sql. But maybe only support PostgreSQL by then.
Robin Shen commented 1 year ago
Forget to mention that I tested with MySQL.
Marcos de Oliveira commented 1 year ago
I'm not too much into java's world but couldn't something like flyway or liquibase be used to handle migrations instead?
Robin Shen commented 1 year ago
As far as I know they also need you to write sql. The sql may also need to be tuned for different database type.
Hi @robin, today I upgraded my test instance to 8.0, which is really easy by the way as I'm using docker. But while watching the upgrade logs, I was wondering, how does OneDev's migration style scales? How big is this instance's Database and what is the largest one you know of? I'm asking because it is not that common for database migrations to be done this way (exporting and importing the whole database to/from XML). A pro of doing it this way is that it is very easy to migrate to different databases, but I guess it would be way more performant to do traditional alter tables for regular migrations.