[Koha-devel] Update database changes proposal [IMPORTANT]

[Chris Nighswonger]

On Thu, Nov 24, 2011 at 10:20 AM, Paul Poulain
<paul.poulain at biblibre.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 24/11/2011 13:22, Robin Sheat a écrit :
>> Op 25-11-11 00:49, Ian Walls schreef:
>>> I do like the idea of hashes... but looking at it, we'd
>>> essentially be mimicking the data structure we already have with
>>> Git commits.  Plus, readability goes down.
>>
>> Is readability an issue here? I was thinking a process like:
>>
>> 1) on each page (and this'll improve heaps when we get persistence
>> :) the list of patch files is build, concated, CRCed.
> There are 2 strong opinions here:
> * upgrade is a process you know you're doing, so no need to check on
> every page
> * upgrade is safer if you check often if you're uptodate: the computer
> must fix human mistakes.
>
> Maybe a middle solution would be to have do a check on the login page
> only (or on mainpage.pl ?). As it's mandatory to log-in on the staff
> interface, that seems fair.

I tend to agree with Paul here. Checking at login for up-to-date deps
seems to be the best way to go, introducing the least overall latency
from the user's prospective.


>
>> Perhaps a quick hash/CRC of the filenames of the patches that have
>> been applied? Should be quick to generated and test, and will tell
>> us immediately if we need to run again.
>
> In a few months, we will have 40 different files. And hashing/CRCing
> 40 files is not negligible. We want to improve perfs, so I think it's
> a wrong idea. On the login page though, I think it's something we can
> afford.

Of course, we could always relegate the hashing/CRCing *and* update
check to a cron job which runs once very <a-time-with-low-system-load>
and gives an appropriate status indication on mainpage.pl.

Kind Regards,
Chris