https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27880
--- Comment #14 from Julian Maurice <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
