[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 #179 from Chris Nighswonger <cnighswonger at foundations.edu> ---
(In reply to comment #178)
> > - 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.

I'll test this out today.

> > - 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?

I used the included sample files:

installer/data/mysql/versions/update_sample.pl.sample
installer/data/mysql/versions/update_sample.sql.sample

> 
> > - 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).

Ok

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