[Koha-bugs] [Bug 7167] updatedatabase improvements

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167

Jonathan Druart <jonathan.druart at biblibre.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Failed QA                   |In Discussion

--- Comment #101 from Jonathan Druart <jonathan.druart at 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.

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.