http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167
--- Comment #113 from Paul Poulain <[email protected]> --- All the tests we made with Jonathan: Tests made: • start from a clean situation (drop the 3 tables created by the new mechanism) • checked that the old updatedatabase is still working by ∘ adding a 3.09.00.028 update, that is empty ∘ checked that we're redirected and the update is OK • Created a 3.09/sample.sql that contains "UPDATE systempreferences SET value='nothing' WHERE variable='NOTHING_TOO';" with a comment "test doing nothing" ∘ verified that, on mainpage, we're redirected to new updatedatabase ∘ verified that, trying to acces, unidentified, to a page (in circulation), we're redirected to new updatedatabase ∘ going to mode DEBUG=1 in Apache config, confirmed that the button "Execute" appears. Checked that DEBUG=0 make the link disappearing • Tested the 2 sample files (the .sql.sample and the .pl.sample) by copying them in 3.09/ directory ∘ Checked that Koha displays "2 updates available", let apply both in one click (UPDATE ALL) • Tested that forcing applying a given update (by manually entering the number) result in a message saying it has already been executed • checked that, if you have 2 files with the same content (ie: same md5sum, but not same name), the installer detect it's a duplicate • Created an invalid update file, ∘ Checked that applying it result in a message, with a link to force "mark as applied". ∘ Checked that the link mark the DBRev as applied and the updater understand it must not bother • Verified what happen when you have an invalid .pl file that does not even compile ∘ checked that there is an error thrown ∘ checked that the Perl error is reported (if the pl is invalid, it means the patch has not been applied, the "librarian" is a developer, displaying the Perl error is relevant) ∘ checked that you can't "force OK" this error = the .pl must be fixed, no reason to be able to force • Verified non numeric behaviour ∘ created a file 3.09/Bug_1234.sql ∘ Tested that it appears first and can be applied ∘ Tested that, once the but has been renamed to a number (ie: it has been pushed), Koha detect it's a duplicate already applied ∘ Possible improvement = if you apply many non-numeric DBRevs because you're testing, they all appear in first place. This can be fixed by removing the entries in tables updatedb_error, updatedb_query, updatedb_report. An improvement could be to have this in the staff interface. For now: ‣ DELETE FROM updatedb_error WHERE version=?; ‣ DELETE FROM updatedb_query WHERE version=?; ‣ DELETE FROM updatedb_report WHERE version=?; • Checked that, in CLI, misc/bin/updatedb.pl --all execute all available DB updates • Checked mix of old and new updatedatabase mechanism: ∘ Applied some new system revisions ∘ Added some lines in installer/data/mysql/updatedatabase.pl, and checked the old versioning system runs -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
