[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 #14 from Julian Maurice <julian.maurice at 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.