[Koha-bugs] [Bug 23073] wiki.koha-community.org needs updating to a later version

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23073

--- Comment #10 from Thomas Dukleth <td-koha-bugs at agogme.com> ---
Database migration from MySQL now functions with not only no errors but also
with no warnings.

I have resolved all 'data truncated' warnings for various columns.  In some
cases, setting a default value appropriate to a particular MySQL column as
NULL, 0, or '' was sufficient.  In a few cases, I have altered the MySQL column
sizes to accommodate a larger data size than the defaults set by Mediawiki for
MySQL.  The difference which has allowed Postgres columns having larger data
size than the size defined for for the same column in MySQL is that the
Postgres columns at issue have a type text without any size constraint while
the same column in MySQL often has a small size constraint.

No longer having 'data truncated' warnings is very good but a little more
checking should be done.

For the cases of default value issues, it will be better to recheck my
particular choices in the problematic columns for whether NULL, 0, or ''
correctly align with default values set for the columns for MySQL.  Despite now
avoiding all warnings, I initially took a trial and error approach to solve as
much as I could in a sprint without sleep shortly after eliminating all errors
and it is possible a choice or choices might not be quite correctly aligned or
at least after doing my course of jury duty I cannot remember perfectly well
how thoroughly I had checked before jury duty.

For the cases of Postgres having a larger data size than defined for the column
in MySQL all the alterations I made to the matching MySQL columns size limits
were made by trial and error and should at least be more closely aligned with
what is actually necessary.  Unlike the earlier errors, the 'data truncated'
warnings do not give helpful information to identify offending rows. 
Particular MediaWiki implementations might need modification of the column size
defaults to accommodate actual use and the case of Wikipedia has many but the
modifications should not be unnecessary it is possible that some particular
rows might have some buggy data from a code bug or a buggy user action.   

The columns for which I altered the maximum size may not generally have great
consequence but there is one key column or key-like column affected,
categorylinks.cl_sortkey for sorting titles properly with efficiency within a
category.  The cause of exceeding the size limit could be how we use the wiki
with some informative verbose titles, however, it may that any extra long page
titles are an accident or traces left over from spammers where the content has
presumably been deleted but traces are left in the database.  Running
updateCollation.php to recompute sort keys for all pages would allow setting
the column size back to VARCHAR(70) without an associated sorting problem.

In two other cases, the column size limits which I found to work are well more
than an order of magnitude greater than the column size defined for MediaWiki.

I will try to query for rows which have excessive data size in the particular
columns if I can find an efficient method to do so.  It may be helpful to use
some combination of aligning the column size better for the actual data and/or
and choosing to truncate some column data without triggering any warning where
it is obvious that excessive data was created by some obvious accident, such as
leaning on the keyboard without intent.

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