http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |In Discussion --- Comment #101 from Jonathan Druart <jonathan.druart@biblibre.com> --- (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.
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
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. 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 ?
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
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 :) ) 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.