https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27880 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- I'm a fan of storing database migrations state in the database. I use that strategy with other apps I write/support. But I'm not sure I follow the position below... (In reply to Julian Maurice from comment #9)
RM/RMaint won't need to rename the file and update the version number. There will be no distinction between a "dev update" (located in atomicupdate directory) and a "prod update" (located in db_revs directory). It becomes just like any other piece of code: it doesn't need to be moved once pushed/backported.
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 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. But I might be misunderstanding what you're proposing here.
Also DB updates will never be executed twice (currently this can happen when switching from a stable version to another, since DB updates are often backported) so they won't need to be idempotent and should be easier to write. For instance there is no need to check if a column exists before adding it because that column cannot exist before the update was executed.
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. -- You are receiving this mail because: You are watching all bug changes.