[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 #177 from Chris Nighswonger <cnighswonger at foundations.edu> ---
Below is the log of my testing.

At present there are three bugs (marked BUG) which prevent me from signing off
on these patches. It would be good if someone else could run through this and
verify these bugs as valid. Perhaps Jonathan can as well.

---------------------------------------------------

- Started from a fresh, default DB
- git-bz apply 7167
- Added a dummy update to the old updatedatabase.pl to verify functionality
- BUG: Koha fails to pick up on the version change, and I am taken to
mainpage.pl
- Created a 3.09 subdir, moving the included sample files there.
- Refreshing mainpage.pl results in detection of the test update; I am
redirected to admin/updatedatabase.pl
- I am notified that one update is available although there are two.
- I have DEBUG set and correctly see the "Execute" option as well as options to
"Update all" or "Update" each.
- Unsetting DEBUG properly results in all options except "Update all" being
removed.
- Noting that both files update files have the same base name "sample_update,"
I rename one "sample_update_1" and the interface now correctly shows that two
updates are available. (Note: We might want to document that. I suspect it is
preferrable to avoid duplicate filenames as much as possible regardless of the
differing extensions.)
- 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.
- Attempted to force installation of PL update which was already installed and
correctly received this message: "update_sample_1 --
/home/cnighswonger/Repositories/koha.3.2.labels/installer/data/mysql/versions/3.09/update_sample_1.pl
already executed in version update_sample_1 : same md5
(839b2b743adfda1ce905b1a99f2daecd)"
- Created a duplicate PL update with the same md5sum as the previously applied
PL update; the updater recognized the update and redirected properly; upon
attempting to apply the update, I correctly received the following message:
"update_sample_2 --
/home/cnighswonger/Repositories/koha.3.2.labels/installer/data/mysql/versions/3.09/update_sample_2.pl
already executed in version update_sample_1 : same md5
(839b2b743adfda1ce905b1a99f2daecd)"
- Created invalid PL and SQL update files; Selecting "Mark As Applied" behaved
as expected in both cases.
- Created a PL update file with a huge syntax error in it; Upon attempting to
apply it, the updater correctly returned the following error message:
"update_sample_4 -- Load functions in update_sample_4.pl failed (I can't load
/home/cnighswonger/Repositories/koha.3.2.labels/installer/data/mysql/versions/3.09/update_sample_4.pl.
Please check the execute flag and if this file is a valid perl script (syntax
error at
/home/cnighswonger/Repositories/koha.3.2.labels/installer/data/mysql/versions/3.09/update_sample_4.pl
line 24, near "....." ) at
/home/cnighswonger/Repositories/koha.3.2.labels/C4/Update/Database.pm line 372.
) "
- 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.
- Created a non-numeric SQL update named bug_1234.sql; Updater detected this
update and placed it at the top of the list; Application worked as expected.
- TRUNCATED updatedb_error, updatedb_query, updatedb_report; verified that the
updater picked up all updates as unapplied
- Verified that 'misc/bin/updatedb.pl --all' applied all updates as expected.

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