[Koha-bugs] [Bug 13068] New feature for DB update and sandbox

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

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

--- Comment #17 from M. de Rooy <m.de.rooy at rijksmuseum.nl> ---
(In reply to Paul Poulain from comment #14)
> there are only a few updates that requires perl, so I thought it could be a
> later enhancement. But i've nothing against an immediate one ;-)

If we start doing more with DBIC, we should probably stop with db revisions in
sql format, but use the perl format.

> +1 for the cleanup patch. Can you tell me what you made to be sure those
> files can be removed safely ? I tried, but was not sure of avoiging a side
> effect. Thus my use of another directory.

I have git-grepped atomicupdate first. This brought up the two exceptions
immediately. I have git-grepped the 15 removed filenames: no results. I have
glanced thru these files: Most of them have been converted to db revisions in
updatedatabase (no exhaustive research however). Enough evidence to remove
them.

> My main comment with your patch is the workflow.
> ON A DEV INSTALL :
>  * dev submit a patch with a db update. On 1st run, the update is applied.
> On the next ones, it is not, because it's in the syspref
>  * the patch is signed-off / qa-ed, puched (and get a number)
>  * on the next run, the patch will be applied and an error thrown (but not a
> problem according to me, because it's a dev install) The syspref is cleaned
> (which is OK. A potential side-effect can happen, in case the developer has
> applied 2 patches, one that has been pushed, one that hasn't. But that would
> just throw a sql error, which is fine, because it's a dev setup)
> 
> ON A PROD SERVER :
>  * sysop update Koha
>  * on 1st run, the update is applied, the version is update, syspref
> untouched
> => no change in the behaviour.
> 
> If I'm right, then I'm fine with this behaviour

That describes the workflow correctly imo. Note that if you are really
cautious, you should not update the codebase and run a official db revision
after having changed the db structure with a dev update. Strictly speaking, you
should first revert the dev update somehow or restore your database. In
practice, you (and I) will not always do that. But at that point we should know
what we are doing!

Thinking about that, we could make a small addition to the counterpatch and a
real syspref that controls dev updates with four modes:
[1] DevUpdateControl= PROD for production machines: Do not execute
RunRemainingDevUpdates, so only official db revs. (Default behavior?) 
[2] DevUpdateControl= RESET: Reinstall dev updates after each official db rev.
This is what my counterpatch now does.
[3] DevUpdateControl= ALWAYS: Run the dev updates at each upgrade (as your
patch does). This actually ignores the local pref listing the applied ones.
[4] DevUpdateControl=TRACK: Only install new dev updates. So do not reset the
local pref. This should not be recommended imo; you should know what you are
doing..
Note that changing or clearing the local pref that lists the applied dev
updates, is another 'smart' way to mimic modes 3 and 4 now already.
What do you think?

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