[Koha-bugs] [Bug 7167] updatedatabase improvements

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167

--- Comment #79 from Paul Poulain <paul.poulain at biblibre.com> ---
(In reply to comment #77)
> (In reply to comment #76)
> > question : if you're in user mode, it means you're running a published
> > version right ? So there should not be any unnumbered dbrev ?
> > conclusion = isn't the current behaviour correct ?
> Update should only list/execute the unnumbered ones. You could have a
> published version plus some custom work. You install that in dev mode and
> then put Koha back to user mode. I guess that means that you normally should
> not have unexecuted unnumbered dbrevs..

I feel we're misunderstanding ourselves:
* if you're on a production server, you've only numbered DBrevs + your own
local revisions (that can be numbered -bad idea- or no)
* if you're on a test/dev server, you've numbered DBrevs (pushed already), plus
unnumbered DBrevs that comes from patches you want to test.

It's not related to being in dev mode or no. The dev mode just let you choose
DBrevs one by one, where the normal mode apply everything, and that's all.

> > Couldn't we also decide that 3.8 DBrevs are made on the old
> > updatedatabase.pl, DBrevs for 3.10 are in the new one ?
> > So no need to backport this enhancement to 3.8.
> Good for me. But this issue will come up again  between 3.10 and 3.11. You
> will have dbrevs in 3.10 folder; they are a subset of the 3.11 folder.
that's not a problem = you'll have to apply all patches coming from any folder
anyway, isn't it ?

> New (minor) point: C4/Update/Database: New dependency introduced: Can't locate 
> File/Find/Rule.pm in @INC. Do you really need this one? You only need to get some file 
> names? Just use glob?
jonathan says glob doesn't handle recursivity, so this package fit our needs
better.

Jonathan will submit a patch that :
* check dbrev on check auth page
* add the cookie to avoid duplicate login
* delete 3.9 from old updatedatabase, to start from a clean situation = 3.9-10
=> everything in a 3.9 directory.

The workflow would then be =
* if you submit a patch that update database and should be ported to 3.8 => use
the "old" updatedatabase.pl script
* if you submit a patch that update database and will be for 3.10 => use the
new mechanism and provide a version/bug NNNN.sql file. The RM will take care of
moving it to 3.9/dbrevnumber.sql when pushing

-- 
You are receiving this mail because:
You are watching all bug changes.