Conversation
221d0e6 to
b30193e
Compare
f18f36a to
a992df7
Compare
Yes, no one will run a manual command after the update. When it should only take a couple of seconds I would say let's do it with a sorry, but we can't help it. |
773e844 to
2d22463
Compare
|
/backport to stable23 |
|
/backport to stable22 |
|
/backport to stable21 |
2d22463 to
5fbecef
Compare
5fbecef to
02dd6fe
Compare
Signed-off-by: Julius Härtl <jus@bitgrid.net>
02dd6fe to
99b2cf8
Compare
|
Bumped the autoloader |
|
Test failing are unrelated to this PR and I'm working on it |
| $update->update('jobs') | ||
| ->set('argument_hash', $update->func()->md5('argument')); | ||
|
|
||
| $update->executeStatement(); |
There was a problem hiding this comment.
executeStatement is not available in stable21
There was a problem hiding this comment.
Still the correct way forward, but stable21 backport should be adjusted then
There was a problem hiding this comment.
I'm very surprised this was not caught on the 21 backport CI
There was a problem hiding this comment.
We don't have CI which runs all the migrations and there is no test for it.
Always had the idea of installing base-ref in an integration test and then performing an upgrade
There was a problem hiding this comment.
But wouldn't psalm catch a usage of a non-existent method?
Based on #30358
Fixes #28467
Adding a hashed argument column in order to allow to check if a job already exists with an indexed SQL query instead of filtering by the content of the
varchar(4000)argument column.@nickvergessen @skjnldsv The update time seems pretty reasonable to me when doing some tests with fake data, but if there are any concerns on having that done in the migration itself, we could have a separate occ command and allow admins to do this separate from the upgrade. Any objections on that?