Моят личен и професионален живот

2019-01-31

Моите MySQL бъгове

Откакто започнах да използвам MySQL 3.23.x пред годините ми в университета се опитвах да решавам проблемите си сам както с другия свободен софтуер и софтуер с отворен код, който използвах. Първоначално беше повече обучение (или липса на знание ако щете), но след това проблемите ставаха по-сложни и трудни за решаване. Е, успявах повечето пъти, така че не вземах в предвид докладване на бъгове или търсене на поддръжка. Обаче еко системата на  MySQL порасна от тогава, софтуера стана по-сложен и базата с изходен код се увеличи значително, така че днес е наивно да се смята, че човек може да оправи всички проблеми, които среща без да се задълбава в вътрешните елементи на продукта или разчита на професионална поддръжка. Първото е възможно само за MySQL разработчици добре запознати с базата с код и големи организации като Facebook, Booking, и т.н., които имат специализирани екипи и редовно допринасят кръпки. Второто зависи от вас и разбира се компанията предоставяща поддръжка.

Не съм докладвал много бъгове за MySQL - само 21, но вече смятам да докладвам всичко което открия, което изглежда като бъг, защото това е правилното нещо. Може и да се справя с проблема сам, но някой може да се натъкне на същото и трябва поне да е наясно, че това е познат (и евентуално вече решен) проблем. С всеки един от тези научих по нещо малко, така че тук отдолу правя преглед на бъговете си до сега описвайки тяхната съдба в хронологичен ред.
  1. Бъг 20098 (първият ми) беше докладван на 2006-05-26 и е със състояние "No Feedback" от 2006-07-01. Беше за Query browser търсещ файл, който не съществува (preferences.glade). Бях забравил за този и открих, че е затворен по-късно, защото не съм предоставил обратна връзка, което е забавно, защото бях предоставил поисканата информация...
  2. Бъг 69459 беше докладван на 2013-06-13 и е в състояние "Can't repeat" от 2013-12-24. Беше за MySQL Workbench сриващ се при въвеждане на точка в SQL низ когато е разрешено автоматично довършване на кода. Докладвах бъга за версия 5.2.47 CE, но бях посъветван да пробвам 6.0.7, която работеше, така че бъга не получи повече внимание тъй като 5.2 серията не получи повече обновления.
  3. Бъг 73076 (първият ми потвърден и оправен) беше докладван на 2014-06-22 и е със състояние "Closed" от 2014-08-26. Беше за MySQL Workbench всъщност записваш промените в набор с редове когато само са приложени. Беше гаден бъг правещ ежедневната ми работа с Workbench трудна, тъй като трябваше да внимавам да не приложа (извинявам се запиша) твърде рано. Проблема се появи в 6.0.x, 6.1.x и беше оправен в крайна сметка с пускането на 6.2.2 на 2014-09-05 (виж бележки към версия) след като беше потвърден от поддръжката.
  4. Бъг 73079 беше докладван на 2014-06-23 и е в състояние "Closed" от 2014-09-15. Беше за MySQL Workbench, който не опресняваше клетката след задаване на стойността на NULL. Засягаше 6.1.x и ранните 6.2.x версии. Въпреки, че не беше официално потвърдено, за мен това беше регресия, но по-важното е, че беше оправен с пускането на 6.2.3 на 2014-09-23 (виж бележки към версия).
  5. Бъг 73708 беше докладван на 2014-08-25 и е със състояние "Closed" от 2014-12-01. Беше за MySQL Workbench моделите, които бяха напълно разбъркани. Забравих този за няколко месеца и предоставих поисканата обратна връзка после, за да разбера, че проблема е вече оправен с пускането на  6.2.4 на 2014-11-20, въпреки че нищо не беше споменато в бележките към версия.
  6. Бъг 73770 (най-стария ми все още отворен) беше докладван на 2014-08-29 и все още е в състояние "Verified" от 2018-02-05. Представлява заявка за нова функционалност в MySQL синхронизатора между модел и база с данни да показва действителните разлики. Който е ползвал тази възможност би трябвало да знае, че прилагането на промените от модел в базата с данни може да бъде доста досадно, защото винаги има някакви неочаквани промени и още повече такива, които не можеш да разбереш. Виждаш само скрипта за обновяване, но ще бъде хубаво да се виждат действителните разлики, което в някои случаи може въобще да не са разлики (виж 90772 по-долу).
  7. Бъг 82202 беше докладван на 2016-07-12 и е със състояние "Closed" от 2018-01-31. Беше за невъзможност за свързване на Connector/ODBC 5.3.6 към споделената библиотека libmysqlclient.so заради неопределени символи (напр. my_malloc, my_free, и т.н.). Проблема беше бързо обяснен, но след това затворен с "Not A Bug". Беше отворен отново след като Fedora отговорник докладва същия проблем и в крайна сметка оправен с пускането на Connector/ODBC 5.3.10 на 2018-01-30 (виж бележки към версия).
  8. Бъг 84951 (първата ми предложена кръпка) беше докладван на 2017-02-10 и е със състояние "Duplicate" от 2017-02-12. Беше за проблем с изграждането на MySQL Workbench 6.3.9, заради компилационни грешки в jsonparser.cpp и jsonview.cpp, за които предложих кръпка. Бъга беше направен двойник на 84886, който също съдържаше кръпка предоставена два дена по-рано, но беше затворен на 2018-05-14 като "Won't fix", защото те "вече не поддържат 32 битови системи" (!?).
  9. Бъг 89608 беше докладван на 2018-02-09 и е все още в състояние "Verified" от 2018-02-13. Това е заявка за нова функционалност за това съобщенията за изискванията към паролите в MySQL Workbench да отговарят на конфигурацията на сървъра, така че да са по-полезни. Предоставих примерен код за това как може да бъде направено и дори написах SQL функция за да пробвам идеята.
  10. Бъг 89615 беше докладван на 2018-02-10 и е със състояние "Unsupported" от 2018-08-23. Беше за неуспех с изграждането на MySQL Shell 1.0.10, заради пропадаща компилация за неопределени vio* функции. Беше свързан с 82202 и въпреки че беше потвърден по-късно беше затворен с обяснението, че "MySQL Shell 1.0 вече не се поддържа и трябва да се ползва 8.0 вместо това" (!?) на което реагирах малко грубо, но наистина не разбирам такива отговори.
  11. Бъг 90619 беше докладван на 2018-04-25 и е със състояние "Duplicate" на 79315 от 2018-04-25. Беше за това, че MySQL Installer не предлага надграждане от MySQL 5.7 до 8.0, което беше обяснено като "не е бъг", защото "работи според очакванията", така че явно MySQL Installer не поддържа надграждания между главни версии. Надявам се това да се промени в бъдеще.
  12. Бъг 90620 (първият ми от серия) беше докладван на 2018-04-25 и е все още в състояние "Verified" от 2018-04-26. Този е за MySQL Workbench 8.0.11's SQL редактора, който показва грешка на SELECT заявка с прозоречни функции. Не бихте очаквали MySQL Workbench имащ същата версия като сървъра да не поддържа новите възможности на сървъра, но повече за това по-късно.
  13. Бъг 90727 беше докладван на 2018-05-03 и е със състояние "Closed" от 2018-06-01. Беше за невъзможност да се свърже Connector/C++ 1.1.11 поради липсващи mysql_sys и mysql_strings библиотеки. Оказа се регресия от някакви специфични за Solaris промени, които не са направени Solaris специфични. Свързах се с разработчика и беше обявено за оправено в 1.1.12, която излезе на 2019-01-28 (виж бележки към версия), така че за 1.1.11 трябваше да закърпя сам.
  14. Бъг 90772 беше докладван на 2018-05-06 (St George's Day) и е все още в състояние "Verified" от 2018-05-09. Беше за MySQL Workbench синхронизатора правещ разлика между варианти за избягване на единични кавички (напр. израза COMMENT 'Currency\' symbol' е различен от израза COMMENT 'Currency''s symbol'). Това е защото MySQL Workbench позволява избягване с наклонена черта и сървъра го приема за изпълнение, но след това го пренаписва като избягване с единична кавичка. Така, при следващата синхронизация разликата остава (т.е. все едно не сте синхронизирали въобще).
  15. Бъг 90876 беше докладван на 2018-05-15 и е със състояние "Closed" от 2018-06-21. Беше за MySQL Shell 8.0.11 даващ грешка 5115 при добавяне на документи към колекция в 5.7 сървър, но това за което беше всъщност е автоматично създавани идентификатори както обясних в подробности в статията ми MySQL Shell и автоматичното създаване на идентификтори за документи. Този предизвика обновяване на документацията и тъй като никой друг нямаше този проблем предполагам, че е добре, но за мен такива проблеми чупят обратната съместимост.
  16. Бъг 91841 беше докладван на 2018-07-31 и е със състояние "Closed" от 2019-01-25. Беше а невъзможност да се изгради MySQL Connector/ODBC 5.3.11, заради компилационни грешки. Успях да оправя компилационните грешки сам (виж кръпка) докато чаках за помощ и обяснение. А обяснението беше, че е двойник на вътрешен бъг, "който обяснява причините за неуспеха", но който не мога да прочета. Забавното нещо в това беше, че имаше повече от 400 реда изтрити от началото на заглавен файл най-вероятно свързано с обновявания на текста с авторското право. Беше оправен с пускането на 5.3.12 на 2019-01-28 (виж бележки към версия).
  17. Бъг 92898 беше докладван на 2018-10-23 и е със състояние "Not a Bug" от 2018-10-23. Смятам този за единствената ми "заявка за поддръжка" и бях доволен, че беше обяснен същия ден.  Беше за това, че ударих несъвместима промяна при надграждане от 8.0.12 до 8.0.13, защото все още имах някои стари изгледи използващи ASC или DESC квалификатори с GROUP BY клауза. В тази връзка искам да благодаря на MySQL подробните бележки към версия, които публикуват, защото в този случай дори да ги четеш внимателно можеш да изпуснеш нещо смятайки, че не те засяга. Поради тази причина е силно препоръчително да се ползва Upgrade Checker Utility на MySQL Shell, който може да ви кажеш за грешки със съвместимостта и проблеми предварително.
  18. Бъг 92900 беше докладван на 2018-10-23 и е в състояние "Verified" от 2018-10-23. Този е за това, че в MySQL Workbench 8.0.13 липсва поддръжка за изрази в DEFAULT, въпреки че функционалността се поддържа от същата версия на сървъра.
  19. Бъг 92908 беше докладван на 2018-10-23 и е в състояние "Verified" от 2018-10-23. Този е за това, че в MySQL Workbench 8.0.13 липсва поддръжка за изрази като части от ключ, въпреки че функционалността се поддържа от същата версия на сървъра.
  20. Бъг 93835 беше докладван на 2019-01-07 и е в състояние "Verified" от 2019-01-10. Това е заявка за нова функционалност за това MySQL Workbench да показва предупреждение при използване на ключова дума като идентификатор (напр. имена на таблици и колони). Отворих го след като Frédéric Descamps предложи това в менение изразено в LinkedIn. Стискам палци да бъде направено.
  21. Бъг 94012 беше докладван на 2019-01-23 и е в състояние "Verified" от 2019-01-23. Този е за това, че MySQL Workbench 8.0.14 не разпознава новата ключова дума LATERAL и дава грешка след нея в SQL редактора. За сега това е последния от серията ми за това, че MySQL Workbench не поддържа възможностите на сървъра, въпреки че са със същата версия. Бъга беше номиниран като MySQL Бъг на деня от Valerii Kravchuk на същия ден.

Надявам се не съм ви отегчил с цялата тази информация отгоре. Не винаги е лесно правилно да се обясни един проблем, но аз имам дост опит бидейки от "другата страна", така че смятам, че знам каква информация е необходима, за да може един проблем да бъде изследван старателно. Все пак докладването на бъгове вероятно е изкуство и очаквам представянето на Valerii Kravchuk на тема How to create a useful MySQL bug report на FOSDEM в Събота.

Някои от бъговете ми са чисто технически (напр. 82202, 84951, 89615, 90727 и 91841) за които съм докладвал всички подробности и все пак обясненията на някои от тях ми изглеждат твърде странни (напр. все не се поддържат 32 битови системи, MySQL Shell 1.0 вече не се поддържа и версия 8.0 трябва да се използва вместо това), въпреки че проблема и това което трябва да се оправи стана доста ясно. Не разбирам как може да не се пуска нова поддържаща версия, когато има отворени бъгове за последната такава версия от серията? Това което производителите трябва да разберат е, че като отговорник за пакети за мен е по-сложно да поддържам кръпки за проблеми, които не се оправят в продукта.

Направих серия от бъгове за неподдържани възможности в MySQL Workbench (напр. 90620, 92900, 92908 и 94012), което ме накара да се замисля за значението на уеднаквяването на номерата на версиите, което беше направено с пускането на MySQL 8.0.11 като общодостъпна версия (виж MySQL 8.0: It Goes to 11!). Както разбирам публикацията, това беше направено, за да ползваме "правилната версия" на всички продукти. Това като цяло е добра идея, но не трябва ли "правилната версия" да поддържа същия набор от възможности като сървъра? Предполага се, че потребителите ще бъдат по-малко объркани ако е така, но за сега определено това не е случая с Workbench. Надявам се ситуацията да се подобри в бъдеще.

Искам да завърша тази статия с няколко завършващи мисли. Като разработчик съм наясно, че никога не може да има софтуер без никакви бъгове. Обаче, като потребител очаквам, когато бъг е правилно докладван и проблема е ясен решението да не трябва да отнема толкова много време, но разбира се това което наистина има значение са приоритетите, а те обикновено са толкова по-високи колкото броя на засегнатите потребители е по-голям.

Няма коментари: