![]() Part of an umbrella task MDEV-33281 for implementing optimizer hints. This commit introduces hints affecting the use of indexes: - JOIN_INDEX, NO_JOIN_INDEX - GROUP_INDEX, NO_GROUP_INDEX - ORDER_INDEX, NO_ORDER_INDEX - INDEX, NO_INDEX Syntax of index hints: hint_name([@query_block_name] tbl_name [index_name [, index_name] ...]) hint_name(tbl_name@query_block_name [index_name [, index_name] ...]) JOIN_INDEX, NO_JOIN_INDEX: Forces the server to use or ignore the specified index or indexes for any access method, such as ref, range, index_merge, and so on. Equivalent to FORCE INDEX FOR JOIN, IGNORE INDEX FOR JOIN. GROUP_INDEX, NO_GROUP_INDEX: Enable or disable the specified index or indexes for index scans for GROUP BY operations. Equivalent to the index hints FORCE INDEX FOR GROUP BY, IGNORE INDEX FOR GROUP BY. ORDER_INDEX, NO_ORDER_INDEX: Causes the server to use or to ignore the specified index or indexes for sorting rows. Equivalent to FORCE INDEX FOR ORDER BY, IGNORE INDEX FOR ORDER BY. INDEX, NO_INDEX: Acts as the combination of JOIN_INDEX, GROUP_INDEX and ORDER_INDEX, forcing the server to use the specified index or indexes for any and all scopes, or as the combination of NO_JOIN_INDEX, NO_GROUP_INDEX and NO_ORDER_INDEX, which causes the server to ignore the specified index or indexes for any and all scopes. Equivalent to FORCE INDEX, IGNORE INDEX. Two kinds of index hints were introduced during implementation: the global kind for [NO_]INDEX hint, and the non-global kind for all others. Possible conflicts which will generate warnings: - for a table level hint - a hint of the same type or the opposite kind has already been specified for the same table - for a index level hint - the same type of hint has already been specified for the same table or for the same index, OR - the opposite kind of hint has already been specified for the same index - For a multi index hint like JOIN_INDEX(t1 i1, i2, i3), it conflicts with a previous hint if any of the JOIN_INDEX(t1 i1), JOIN_INDEX(t1 i2), JOIN_INDEX(t1 i3) conflicts with a previous hint |
||
---|---|---|
.. | ||
charsets | ||
CMakeLists.txt | ||
errmsg-utf8.txt | ||
insert_translations_into_errmsg.py | ||
README.md |
A quicker way for adding new language translations to the errmsg-utf8.txt file
Summary
To generate a new language translation of MariaDB use the following pull request (PR) as a template for your work:
You will notice as part of your translation work, you will have to add your language translations to the file sql/share/errmsg-utf8.txt
which is found in the current directory. This file is long with many sections which can make the translation work tedious. In this README, we explain a procedure and provide a script insert_translations_into_errmsg.py
that cuts down the amount of tedium in accomplishing the task.
Procedure
-
Start by grepping out all the english translations from errmsg-utf8.txt using the following grep command, and redirecting the output to a file:
grep -P "^\s*eng\s" errmsg-utf8.txt > all_english_text_in_errmsg-utf8.txt
-
Next use Google translate to obtain a translation of this file. Google translate provides the ability to upload whole files for translation. For example, this technique was used to obtain Swahili translations which yielded a file with output similar to the below (output is truncated for clarity):
sw "hashchk" sw "isamchk" sw "LA" sw "NDIYO" sw "Haiwezi kuunda faili '% -.200s' (kosa: %iE)" sw "Haiwezi kuunda jedwali %
s.%
s (kosa: %iE)" sw "Haiwezi kuunda hifadhidata '% -.192s' (kosa: %iE)" sw "Haiwezi kuunda hifadhidata '% -.192s'; hifadhidata ipo"
Note that Google translate removes the leading whitespace in the translation file it generates. DO NOT add that leading whitespace back!
-
Give the translated file an appropriate name (e.g.
all_swahili_text_in_errmsg-utf8.txt
) and store it in the same directory witherrmsg-utf8.txt
andall_english_text_in_errmsg-utf8.txt
. These 3 files will be used by the script insert_translations_into_errmsg.py. -
Proof check the auto-translations in the file you downloaded from Google translate. Note that Google might omit formatting information that will cause the compilation of MariaDB to fail, so pay attention to these.
-
Reintegrate these translations into the errmsg-utf8.txt by running the insert_translations_into_errmsg.py script as follows:
chmod ugo+x insert_translations_into_errmsg.py # Make the script executable if it is not.
./insert_translations_into_errmsg.py <errmsg-utf8.txt file>
For example, for the swahili translation, we ran the following:
./insert_translations_into_errmsg.py errmsg-utf8.txt all_english_text_in_errmsg-utf8.txt all_swahili_text_in_errmsg-utf8.txt
The script uses the
errmsg-utf8.txt
file and the grepped english file to keep track of each new translation. It then creates a file in the same directory aserrmsg-utf8.txt
with the nameerrmsg-utf8-with-new-language.txt
. -
Check that the reintegration of the new translations into
errmsg-utf8-with-new-language.txt
went OK, and if it did, renameerrmsg-utf8-with-new-language.txt
toerrmsg-utf8.txt
:mv errmsg-utf8-with-new-language.txt errmsg-utf8.txt
-
In the header of errmsg-utf8.txt make sure to add your language long form to short form mapping. E.g. for Swahili, add:
swahili=sw