https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23073
--- Comment #10 from Thomas Dukleth <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
