[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 #178 from Jonathan Druart <jonathan.druart at biblibre.com> ---
(In reply to comment #177)
> Below is the log of my testing.

Hi Chris,
Thank you very much for testing :)

> - BUG: Koha fails to pick up on the version change, and I am taken to
> mainpage.pl

Yes, a line has to be replaced by the RM when this patch will be pushed (see
installer/instal.pl l.323 to set $koha39 with your last (+1) version number.

> - Tested install of updates by clicking "Update All." The PL file applied
> fine while the SQL file failed due to some SQL syntax error.
> - Text of error as displayed in the interface: "update_sample -- Error :
> 1064 => You have an error in your SQL syntax; check the manual that
> corresponds to your MySQL server version for the right syntax to use near
> 'INSERT INTO `systempreferences` VALUES ('TestSyspref3','2','set the level
> of err' at line 2;"
> - BUG: A quick look at the SQL file shows that the SQL for the "complex"
> example is correct; I'm assuming that there is a bug in the updater code.

I can't reproduce that. Could you provide your test files please?

> - BUG: I was not given the option of marking the aforementioned update as
> applied and consequently could not navigate away from the updater interface.
> This was unexpected behavior to me, as I would have expected to be able to
> return to normal operation of the staff interface in spite of the update
> failing. This probably needs to be added. If we do not want to permit
> forcing of this sort of thing, we should offer the user the option of
> completeing the updates at a later time perhaps setting a highly visible
> notification on the staff homepage to that effect. In any case, a more
> graceful recovery should be possible since we don't know the circumstances
> surrounding the user when such failure occurs.

If a .pl file raises an error (here a syntax error), the queries are not
executed (inevitably). So there are no entry in the sql tables and we don't
know the "history" of this file. On master, the RM will not push an
unexecutable file; on a dev install the developper will know what happen and
will have to fix that (a simple way is to remove or move the file out of the
versions directory).

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