https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27880 --- Comment #14 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to David Cook from comment #10)
Depending on when the update is pushed/backported, wouldn't the RM/RMaint need to rename the file so that it fits into the right order? If the developer creates a migration in 2021 but it isn't pushed until 2023, it'll be out of order with all the other migrations. I think it's not a problem. Migrations don't need to be run in "push order". What matters is that a migration is executed after any other migrations it might rely on, which are all the migrations already existing in master at the time of writing the new migration (+ any migrations contained in bug reports dependencies). The timestamp prefix ensures that.
I suppose you could argue that it'll be applied at the right time because all the other migrations would've been applied already, but I don't think that would work for upgrades across multiple versions. I don't understand, or I don't agree :) If stable has migrations A B C D E and oldstable has only A C E, when switching for oldstable to stable, migrations B and D will be executed. Why do you think it wouldn't work ?
I reckon it's always good practice to check before adding things. I've noticed a lot of database discrepancies, so you never know what Frankenstein's monster of a database you might have. Yes I might have been over optimistic with this. Things can go wrong even when migrations are executed only once.
(In reply to David Cook from comment #11)
I don't understand the manual work for RM/RMaints so maybe we can get a more in-depth explanation for that? Move/rename of the atomicupdate file + increase of Koha version. It won't be necessary with these patches.
I do want to reiterate that I think recording database migrations in the database is a good idea. Although what do we do for historical migrations? Do we just choose an arbitrary point to start recording from? Yes. The arbitrary point would be when this patch is pushed, which will record the first migration. It might be a good idea to push it early in a release cycle, before any migration. Since it removes the 4th part of the version number, it may cause confusion if we do it after other migrations have been included (23.11.06.000 -> 23.11.06.001 -> 23.11.06 (???))
(In reply to David Cook from comment #12)
Julian, you might also find bug 34088 interesting.
In that case, I'm just short circuiting when the database version is equal to the code version, but if we stored migrations in the database I was wondering if there could be an easy way of telling whether or not there were any outstanding migrations to run (in a high performance way). Hmm.. Probably not :/
(In reply to David Cook from comment #13)
I think Koha::Migrations->pending_migrations is actually a significant win for these patches.
It gets a big hashref of all past migrations, and then it checks in O(1) time whether a file has already been used.
So we only have 1 database hit, and we have an efficient check per file.
Of course, the time it takes to check for pending migrations will degrade over time as the list of migration files grows. But that's a problem that we already have. It would be interesting to see how much time it takes to process a directory of 100, 1000 and 10000 entries (we are getting close to 1500 updates actually in master)
-- You are receiving this mail because: You are watching all bug changes.