http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167
Jonathan Druart <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |In Discussion --- Comment #101 from Jonathan Druart <[email protected]> --- (In reply to comment #100) Hi Marcel, First thanks for your umpteenth QA. When I proposed this path, I didn't think that would be as difficult to integrate :) >Sorry, I do not understand. I do not see any logic in the code that makes that >happen. I do not think that we actually need that either. I don't understand neither :) When I imagined and developped this patch, I wanted something robust and intelligent. Most part of the routine of the new module (C4/Update/Database.pm) is present to provide these functionnalities. If we wanted for Koha a simple update database script, it would have been created several years ago. Because this script could have been written in 1 day with 100 lines of code. To provide a more robust script, we have to accept some compromises. For example, each .pl update version must contain a _get_queries routine to be called by a parent script. Perhaps it seems less easy to write, but I don't think so. Indeed, all the common part of code (like get a dbh, execute, get errors (or not), etc.) are factorised. However, either .pl and .sql are "intelligent", or both are "stupid". But it will be weird if they have 2 differents behaviours depending on their extensions. > If a sql command in a .sql file spans two lines, the patch does disapprove it Have a look at attachment 10549, file installer/data/mysql/versions/3.09.00.014.sql It's a feature :) If you peeks at the C4::Update::Database::get_queries routine, you can see a management of the DELIMITER mysql statement. It permits to write something like: -- some comments DELIMITER // INSERT INTO my_table (field1, field2) VALUES ("value1", "value2")// I think it is what you want, isn't it ? > Note: IMHO we should not write a sql parser. And if we accept .sql files, we > should be able to handle them all. I still strongly prefer to run .sql files > via mysql; this is something that you also expect to happen. See below. If we just want a script like: if ($filename =~ /.pl$/ ) { system( "perl $filename" ); } else { system( "mysql < $filename" ); } 5 lines are sufficient :) > Side note: If a db rev fails, how do I get rid of the Failed-lines on the > update screen? What do you call 'the update screen' ? It is the table containing all versions ? If I get an error like 3.09.00.005 -- This file ( /home/koha/src/installer/data/mysql/versions/3.09/3.09.00.005.pl ) still already execute in version 3.09.00.005 : same md5 (682eb7514afeee03d5ff29824dd8a621) [Mark as OK] I can click on 'Mark as OK'. It will mark this db version as 'It is corrected'. If a new db version contains: -- comments DELIMITER // CREATE TABLE tags (field1 integer); Then, the check_coherency fails (we already have a tags table). It permits to have a personnal message of the failure and translate it into the template. We can simply extend this function to add other verification. Then the screen displays: Report : 3.09.00.044 -- COHERENCY: Table tags already exists ; [Mark as OK] Your datebase is not up to date. 1 update available [UPDATE 3.09.00.044] If you click on the 'Mark as OK' link, the following screen displays 'Your database is up to date' (I agree with you, I could have written: "All your base are belong to us", but it is less comprehensible :) ) > Side note: The About form lists db revs that failed as if they have been > applied correctly. It works like into the actual version. A version is executed and the version of koha is this new version for all cases (failure or success). We consider it is the job of the guy who execute the update to maintain a DB up-to-date. Others comments are technicals and can be fixed. I think we want to be on the same wavelength before we continue this development (especially for the first point). Perhaps, somebody else can given his opinion and open the discussion. I hope will be understood :) -- 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/
