[Koha-bugs] [Bug 27880] Store each database migrations state in database

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27880

--- Comment #10 from David Cook <dcook at 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.