On 03/03/2021 12:25, Julian Maurice wrote:
> Le 03/03/2021 à 11:18, Joonas Kylmälä a écrit :
>> Not really sure it is more work than writing the current db upgrade
>> procedures, maybe tiny bit, and a bit more if you want to be able to
>> revert the DB upgrade as well (which is optional and I don't
Le 03/03/2021 à 11:18, Joonas Kylmälä a écrit :
Not really sure it is more work than writing the current db upgrade
procedures, maybe tiny bit, and a bit more if you want to be able to
revert the DB upgrade as well (which is optional and I don't think we
should even consider that for MVP implemen
Hi,
On 03/03/2021 11:39, Julian Maurice wrote:
> I'm not too much concerned about the "push-test-release" process, but
> more about how we consistently make the code aware of the multiple
> possible database states. Surely we'd have to enforce a new set of rules
> for writing database updates. And
Le 03/03/2021 à 09:44, Joonas Kylmälä a écrit :
I don't know any other software but not sure it is that difficult. What
I gather, we could use e.g. Jenkins to push the code / new debian
package that would be created for every commit. Jenkins would make sure
db schema migration is finished before
Hi
On 02/03/2021 17:56, Julian Maurice wrote:
> Does it mean that the application (Perl) code should be aware of that
> intermediary state where both columns exist at the same time ? If so,
> for how long should it be aware of that old database state ?
Yup. And answer to the second question: as l
On 03/03/2021 09:38, Joonas Kylmälä wrote:
> Downtime, removal of odd maintenance hours and shorter feedback loop are
> the main benefits I see here.
ahah, one more thing I was thinking: I hate to spend time on doing
releases so I wanted to automate so far as just pushing to production
git branch
Hi,
On 03/03/2021 00:47, dc...@prosentient.com.au wrote:
> It seems to me that we would have to train every developer on how to write
> their Perl code and database changes to work with this conceptual model.
Yeah, that's correct if there is DB changes.
> That being said, I am intrigued. I h
0899
Online: 02 8005 0595
-Original Message-
From: Koha-devel On Behalf Of
Julian Maurice
Sent: Wednesday, 3 March 2021 2:56 AM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Rolling DB upgrades
Le 02/03/2021 à 16:00, Joonas Kylmälä a écrit :
> With rolling upgrade
Le 02/03/2021 à 16:00, Joonas Kylmälä a écrit :
With rolling upgrade we would first create another
column with the new name and write & read data to both columns during
the 1st step of upgrade, then in 2nd step when all web server nodes are
using latest version we could upgrade again to newer ver
Correction: "create another
column with the same name" -> create another
column with the *new* name"
On 02/03/2021 17:00, Joonas Kylmälä wrote:
> Hi,
>
> for example if we rename a DB column in Koha now we need to stop all the
> koha web server instances (or they stop responding because because k
Hi,
for example if we rename a DB column in Koha now we need to stop all the
koha web server instances (or they stop responding because because koha
checks that db revision is correct), do DB upgrade, start all Koha web
server instances. With rolling upgrade we would first create another
column wi
Den 02.03.2021 15:33, skrev Joonas Kylmälä:
Hi,
I opened a bug report for introducing rolling DB upgrade support for
Koha. I would like to hear if you have anything to object to that or
should we just go ahead and develop that? :)
I must confess I am not 100% certain what you mean by rolling u
Hi,
I opened a bug report for introducing rolling DB upgrade support for
Koha. I would like to hear if you have anything to object to that or
should we just go ahead and develop that? :)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27832
--
Joonas Kylmälä
Tietojärjestelmäasiantunti
13 matches
Mail list logo
