12 сентября 2018 в 23:24
Заказчик обновил ядро до 8.6.1 и частично отвалился функционал написанных мною модулей (касается в первую очередь запросов к структуре иерархии таксономии):
SQLSTATE[42S02]: Base table or view not found: 1146 Table taxonomy_term_hierarchy doesn't exist
Первое подозрение было на некорректное обновление, но беглая раскопка вопроса и чтение примечаний к релизу показали, что таблица taxonomy_term_hierarchy действительно исчезла, будучи заменена новой таблицей taxonomy_term__parent с расширенной структурой SQL-полей (фактически, это теперь отдельное поле термина, описывающее отношение термина к родителю, см. taxonomy_update_8502).
Возможно, это полезное нововведение, но никак не ожидаемое. Таблица taxonomy_term_hierarchy уже давно стала настолько привычной, что воспринималась как что-то незыблемое (по-моему, ещё с D6). В итоге, видимо, придётся перепиливать несколько модулей в сторону изменения запросов к БД.
У кого какие мысли на этот счёт?
Комментарии
хз, в 7ке всегда использую taxonomy_get_parents или taxonomy_get_parents_all
Для 8ки, вроде так надо - тык
Полезно и ожидаемо. В старой структуре ссылка на родителя не содержалась в объекте термина, что само по себе идиотизм. И влекло за собой ряд глюков, например, невозможность получить родителя термина через jsonapi.
Речь не о простом получении родителя(ей) через стандартные функции API, а о построении SQL-запросов в относительно сложном контексте (когда требуется поиск или SQL-выборка по многочисленным критериям). Когда, например, нужно получить в одном результате запроса одновременно и родителя и какие-то связанные с ним данные из других таблиц. Или, возможно, ещё и смежные термины под этим родителем. Да много таких случаев.
Согласен, что запросы через EntityQuery удобнее в большинстве случаев и теперь что-то будет несколько проще или по крайней мере - логичнее. Но насчёт ожидаемости - ну как-то нет, извините. Сколько кастомных модулей на текущий момент используют taxonomy_term_hierarchy (учитывая, что это был кратчайший/непосредственный путь программного получения структуры таксономии или построения SQL-запросов с учётом иерархии терминов)? Это всё теперь повлечёт повторный рефакторинг, отладку и т.п. Ну вообще - затронута таки одна из ключевых таблиц таксономии в архитектуре Друпала, это всё же не кеш и не поисковый индекс.
Было бы более понятно, если бы отказались от таблицы ещё где-то на инициальных релизах D8.
Эх... Так и напрашивается nasted sets, вместо таксономии "родной".
> Заказчик обновил ядро до 8.6.1 и частично отвалился функционал
Сейчас бы на минорку обновляться не читая ченджлогов.
> Возможно, это полезное нововведение, но никак не ожидаемое.
20 января 2018 это изменение анонсировали. Тогда ещё вроде даже 8.5 не вышел. Всем дали привести всё в порядок. Оригинальный ишью так вообще с 2015 года. Но ишью это никто бы просто так и не нашел, но вот официальный ченджлог и уведомление больше чем полгода уже есть. Плюс упомянуто в релиз нотах 8.6.0.
> будучи заменена новой таблицей taxonomy_term__parent
Ну так пройтись поиском по коду на taxonomy_term_hierarchy в своих запросах и заменить на новую таблицу. Если судить по модулям что использовали эту таблицу прямыми запросами, все решается простой заменой: taxonomy_term_hierarchy на taxonomy_term__parent, taxonomy_term_hierarchy.parent на taxonomy_term__parent.parent_target_id и taxonomy_term_hierarchy.tid на taxonomy_term__parent.entity_id.
> У кого какие мысли на этот счёт?
Изменение крайне полезное и правильное. Все были предупреждены, а кто не успел, решается быстро.
Ничего серьезного не случилось. Впрочем, как я уже написал, это минорная версия. Вообще, клиент на такие и не должен сам обновляться, ну или как минимум спросить разработчика, есть ли там что в 8.6.0 что может поломать сайт. Он же не читает ченджлоги, а если и читает, с высокой вероятностью он не в курсе, заденет его сайт конкретное упоминание или нет. Он так и на 8.7.0 обновится, что-то может развалиться, и на 8.8.0. Безопасно клиенту можно разрешить обновляться только в пределах патч версий, где апдейты уровня Drupal 7.
Хорошо бы скорей таксономию вообще замени на ентити релайшинсы для хэштегов в коробку. вьюсы встроили, хорошо бы и всю остальную модель привести к ER. Безобразие должно быть = единообразным.
Ну вот я, например, ни разу к этой таблице не обращался в кастомных модулях на восьмёрке. Как выше рассказали, переделать - 5 сек.
Надо поковырять, вполне вероятно, что именно так и сделали. Поскольку в названии таблицы есть двойное подчёркивание, то это явно теперь поле, а не какое-то странное свойство. Тип поля надо смотреть в коде или через devel.
Если вы про поле parent. Оно с 8.6.0 теперь entity reference типа, а не самобытное. Именно поэтому и таблицы поменялись. Теперь таблица от entity_reference.
Ну видимо - да, промухал я, каюсь. Или не обратил внимание когда-то. И заказчику тоже я дал благословение на апдейт - он не в первый раз делает самостоятельно. Я прочитал release notes, но именно для 8.6.1, и, поскольку обновление было не с 8.6.0, а с 8.5.x то, конечно, в примечаниях уже ничего не было про taxonomy_term_hierarchy, хотя пресловутая замена таблиц случилась именно в последнем релизе (8.6.1).
По поводу 5 секунд: суммарно на переделку ушло около 7 часов - практически вся сегодняшняя ночь. Причины:
- обращений к taxonomy_term_hierarchy было много - из нескольких различных механизмов.
- помимо переименования названий полей собственно в запросах пришлось отслеживать и переименовывать ассоциативные индексы и имена элементов/объектов в results set (поскольку ряды использовались и далее по коду).
- отладка и тестирование исправлений (половина случаев использует BatchAPI в длительных операциях импорта разных типов данных, пришлось всё прогонять хотя бы на относительно небольших пачках данных).
В общем, морока. И это только в рамках одного проекта, на котором обнаружилась проблема.
Да, о чём и речь. По крайней мере - очень близка, разве что вместо типичного для ссылок на термины 'target_ig' сделали 'parent_target_id'. В целом всё вроде в лучшую сторону, но могли бы таки ещё раз в релизе 8.6.1 сообщить об удалении старой таблицы, это всё-таки существенное изменение в общей механике таксономии.
Тут косяк именно в апдейте минорной версии не читая ченджлоги минорной версии, а не её патч версии, где эти апдейты и не нужно перечислять.
Минорные версии это 8.X.0. Все серьезные релизы идут в X версии, и ченджлоги данных версий описавают всё это очень доходчиво. Патч версии 8.X.Y (Y) описывают только то, что было изменено в них. Как в общем и все релизы.
Если отталкиваться от 7-ки, у семерки только MAJOR.PATCH, а у 8-ки MAJOR.MINOR.PATCH. Поэтому апдейты по MINOR стоит всегда изучать.
Чтобы клиент в следующий раз не нарвался на подобные проблему, лучше обновлять композером, если это уже не сделано. И поставить версию ядру с ~, а не с ^. То есть ~8.6.0 - так он не обновится до 8.7.0, пока руками не будет заменена минорная версия в composer.json или прямым запросом данной версии через composer require drupal/core:~8.7.0. В общем, своего рода защита от дурака и невнимательности. А патч версии в пределах минорной версии будут спокойно обновляться как и в 7-ке. И ничего там не сломается 100%
Тут косяк в том, что полезли обновлять прод без тестирования.
Остальное - следствие.
Это еще не косяк. Был на моей памяти косяк, когда обновлять прод полезли несмотря на тестирование
Ндаа.. поддых буквально..
Всего не упомнишь, при проверке ченджлогов, чего в "своих" модулях на ядро сильно завязано..
Хорошо бы для таких случаев где-то в модуле списочек иметь наименований сервисов, плагинов, таблиц бд и т.п., которые в модуле используются.
И команду драша или консоли, которая упоминание всего этого в ченнджлогах найдет и покажет..
Можно даже не конкретно "имена", а просто "слова" для поиска по ченджлогам , на которые стоит обратить внимание.
Вот кстати ещё один стимул использовать dependency injection вместо статического вызова сервисов - все зависимости как на ладони.
Ну вернуть старую табличку - косяки то исчезнут, а потом дописать синхронизацию, если уж так неохота новую использовать. Как временная мера
Но вообще конечно так не делают. Новая версия не должна кардинально старую перечеркивать, должен быть переходный период, когда обе таблицы бы существовали и работали корректно.
Это функции, классы, методы можно объявить deprecated и выпиливать потихоньку хоть годами. А таблицы - это структура данных. Одни данные не могут одновременно иметь две структуры, поэтому приходится делать так.
Но лично на мой взгляд, если аж 7 часов пришлось переделывать кастом, то тут явно что-то не так - слишком много кастомных запросов в базу, это явно не друпал-вэй.
Но это всё мелочи, я вам скажу. Вот я недавно обновлял один headless проект с 8.3.8 на 8.5 с чем-то. Плюс обновил весь контриб и вендоров. Вот там семью часами не обошлось))) хотя переделывать пришлось в основном по части реакта.
Какую отсрочку не давай, все равно кто-то не успеет..
Тут надо как-то более системно проблему решать..
Помните сколько лет PHP поддерживало старые форматы баз, но уже вводила новые? Вот пример.
А прикинь они с твоей логикой - все, 4-я версия mysql(образно) не поддерживается, теперь только 5-я, а все кто не успел тот опоздал - мы написали, мол не обновляйтесь, угу.
Да конечно могут, что за ерунда. Можно было бы оставить и старую таблицу и писать туда те же данные, и всё.
Но... Но... Но как? О_о. Одни и те же данные, которые хранятся в двух таблицах разом? И параллельно обновляются, и параллельно удаляются? И внешний интерфейс взаимодействия одинаковый?
И в чем проблема? Насколько я помню данные пишутся в итоге в одном месте. Просто будут автоматом ПИСАТЬСЯ в две таблицы. НО система забирать будет уже из новой, а те сторонние модули, которые со старой таблицей работают - из старой.
То есть запись просто параллельно идёт в обе таблицы. Да, будут проблемы с теми, кто пишет НАПРЯМУЮ в таблицы - но кто так делает с таксономией? Обычно же taxonomy_save() максимум идёт.
@xakd
Писать данные сразу в две таблицы?
Поддерживать сразу 2 варианта реализации + поддерживать совместимость между этими вариантами?
Возможно какое-то время это можно, но потом начнутся проблемы движения "дальше"..
Я сильно сомневаюсь, что ради "ленивых" пользователей кто-то(из разработчиков этого функционала) будет жертвовать свое личное время .
Это понятно и логично..
Да, это элементарно. У нас пишет всего одна функция на весь Друпал.
Какую ещё совместимость? Нет. Работаем мы с новой, но зато и старые модули, которые могут брать данные откуда привыкли. Чего тут особо поддерживать то?
Я и говорю, что "какое-то время это можно"..
Но потом один из вариантов начнет дополняться каким-то функционалом..
Во втором варианте, для совместимости это тоже надо будет делать..
потом во втором варианте, из-за специфичной структуры данных, повторить функции первого варианта станет невозможным..
и все..
начинаем с самого начала этого топика..
плюс не забываем, что Drupal это Open Source.
Т.е каждый его разработчик вносит свой вклад в соответствии с какой-то своей личной "необходимостью".
Возможно чешет свое чувство собственной значимости, а в большинстве случаев эта необходимость - скорее всего обусловлена его личным бизнесом (или как там еще он обеспечивает себя хлебом с маслом)
И ничего предъявить по этому поводу этим достойным людям никто не имеет права, просто потому что не имеет-)
Да не скоро и начнет. А пока хотя все понимают, что старую таблицу уже использовать нельзя - и новые модули пишутся уже с новой таблицей, а старый обновляются, ибо ЕСТЬ КУДА ОБНОВЛЯТЬ. И месяцок у людей будет все переписать без обрушивания всей системы
@xakd
Судя по этой информации, времени было достаточно,чтобы переписать свои модули
сколько бы его (этого времени небыло), всегда найдется тот кто неуспел..
Поэтому я немного выше и предложил решать эту проблему системно, т.е. необходим некий иструмент, позволяющий вовремя обнаружить проблему с кастомном модуле, связанную с изменением его зависимостей.
А как переписать, если новой таблицы ещё не было? Да отмазки все это. Так не делают. Я вон предложил аналогию с PHP - сколько тащили ради совместимости? А тут бах и типа разгребайте.
Это из той же оперы, что мол идите в гитхабе ищите что вам надо, какие обновления на сайте вышли - там же предупреждали, мелким шрифтом в некой теме на неудобном с непонятной структуре сайте по-английски полгода назад.
Напиши свой модуль, выложи на орг. Надо всего-то при установке модуля создать ту старую таблицу и заполнить данными из новой. И пару хуков в модуле, чтобы обновлять данные при сохранении термина.
Кто бы оплатил...
Но тут модуля не хватит, тут патчить ядро придется
Ничего не надо платить - это всё совершенно бесплатно. И как я описал выше, не надо патчить ядро, модуль простецкий - на пару хуков, даже без ООП.
Разрабам 100500 раз твердили: юзайте api, не надо лазить в базу напрямую. А раз уж полезли - будьте готовы к тому, что что-то может пойти не так.
Обновление не критическое, нет никакой нужды накатывать его в срочном порядке сразу на прод. Сначала вдумчиво курим diff, затем усиленно тестим то, что изменилось, и уже затем выкатываем это в прод.
А что ж высшие разрабы то стали менять структуру таблиц, если она была такая идеальная, юзай только API? Может как раз не хватало функционала API и приходилось напрямую лезть, что заставило в итоге разрабов переработать весомую часть таксономии?
Да понятно, виноваты сами пользователи, что обновились. Представьте что винду обновили, а она крашнулась? И тут выходят люди, которые говорят - вы че, не читали что ли,что в обновлении, там всего страниц то 10, че обновлялись то? Сами виноваты, Микрософт не причем. Читать надо пользовательское соглашение, там в пункте 18 в подпункте 45 прямо указано, что сначала надо прошерстить весь софт на предмет несовместимости, а потом уж обновлять. А уж если автообновление поставили - то вообще сами виноваты.
Такая ваша позиция как я понимаю.
Нужны гвозди, которыми прибивать понимание опенсурса, не понимают никак...
Просветите плиз, в чем у меня недопонимание? Опенсурс исключает ответственность за продукт?
Все элементарно до невозможности.
Под любой маской "LTS-enterprise-mega-supporting" находится единственная истина:
Каждый ответственен только за свой продукт.
Мы все используем результаты работ других людей, реализовавших свои идеи в коде, под их нужды.
Все что не нравится - реализуется самостоятельно.
При малейших признаках недовольства - перечитываем мантру, написанную капсом.
Так что, нельзя бракованный друпал вернуть назад?
Только если в заводской упаковке и без следов использования.
И деньги полностью вернут? Или только часть?
О! Вернут в полной мере, согласно чеку. С этим проблем нет.
Эээ нет, это продукт они РАСПРОСТРАНЯЮТ, это не под ИХ нужды - он позиционируется как продукт для НАШИХ нужд. Тоже мне бессребреников нашел.
Хотя вы интересно подменяете тему разговора о деловой( в данном случае программистской, не знаю, этикой разработчика) этике юридическими аспектами - мол, юридически они ничего не должны, а значит рот закройте.
Если прочитать не по диагонали, то я не "рты закрываю", а объясняю философию открытого ПО - юзаешь на свой страх и риск, в том виде как дают, если хочешь - переделываешь на то, что нужно тебе.
Юридические там, или мета-физические аспекты - не помогут, если не понять суть.
Кроме разрабов Друпала. Они даже за него не ответственны. Ужас.
Я конечно все понимаю, но с каких пор бесплатность продукта освобождает от ответственности за неприятности и проблемы при его использовании? Что это за извращённое понятие опенсурса?
Какие такие неприятности??
Я вот, не лез к иерархии терминов, и нет у меня неприятностей никаких. Все как часики!
Да у меня тоже, но мы разве от своей колокольни тут пляшем? Мы тут обсуждаем, правильный ли подход у компании, которая выпускает drupal, поступать подобным наплевательским способом.
Как по мне - идиотский и свинский. Мол, мы там полушепотом сказали в ЯНВАРЕ, что КОГДА-НИБУДЬ в 8.6* КАКОЙ_ТО ВЕРСИИ НЕИЗВЕСТНО КОГДА мы удалим важную таблицу в Друпал. А вы пока думайте КАК мы это сделаем, на что заменим, а если не придумали правильно - сами мудаки и жрите что дают, ибо "НИКТО НИЧЕМУ НИЧЕГО НЕ ДОЛЖЕН", опенсурс же.
Боже мой, и вы поддерживаете такой подход к продукту?
Поддерживаю или нет - дело 3е.
Есть лицензия, там все написано.
А, ну перешли в формальный стиль разговора. Типа не прочитали Пользовательское соглашение - ваша проблема. Помнится даже в Южном парке была про это серия прекрасная
В принципе (применительно к моему случаю), ответ уже прозвучал:
Насколько было возможным - придерживались пресловутого drupal-way.
Но исходные вводные (структура данных, полей и сущностей) и общий характер функционала были таковы, что возможностей Entity API и Entity Query API было как минимум недостаточно. Задачи были нетривиальные и довольно сложные - главным образом импорт/синхронизация данных из различных внешних API с выборкой из нескольких буферных/промежуточных таблиц сырых нативных данных.
Т.е. - можно было, конечно, долго пилить и искать труЪ-друпал-вэй (сомневаюсь, что это в итоге привело к ожидаемому заказчиком результату), а можно было выбрать допустимый компромисс между бюджетом и временем. Да и, в конце концов, модули писались под КОНКРЕТНЫЙ проект, не для широкого применения. Заказчик в общем-то тоже знал об этом и совсем не возражал, главное - чтобы была решена задача.
Даже не пытался критиковать это решение. Действительно, бывают случаи, когда средств api недостаточно.
Речь о том, что такие сложные решения требуют особого внимания.
Блин...
Да, понимаю, "ннада именно так, но так нет в API - напишу ка". Все это проходили.
Но чего теперь на релизеров бочку катить то? Сами пишем - сами свои же поделки поддерживаем, разве не такая логика?
Никита выше писал, что это обновление равносильно переезду с 6ки на 7ку - какие тут могут быть возражения и бек-саппортинг?
Никто же не ныл когда структуры полей (CCK) в ядро поместили и поламали всю совместимость в 7ке. А тут вдруг "негодяи и мерзавцы" - слишком мало предупреждений написали... Есть же возможность на 8.5.* оставаться - там не нужно переписывать ничего.
Вы серьезно? Это в вашем понимании опенсурс?
Это где такое было указано? Или это очередная постфактум отмазка? Это счас выйдет обновление у винды, которая крэшанет все системы - а сео выйдет и скажет - мол, это считай 11-я система, мы никому не говорили громогласно, но кто не понял
извините?Да позорище это, а не отмазки.
А знаете почему? Потому что нельзя было обновиться с 6-ки на 7-ку иначе как ручками все переделывая. То есть берясь за обновление 6-7 ни у кого не было недопонимая, что они мол на 6.29 обновляются одной кнопкой. Не надо тут рассказывать, что 8.61 это не 8-ка - выглядит убого.
Ну так никто не запрещает сидеть на 8.5.х, зачем сразу на 8.6 лезть?
Да. Уверен, не только в моем понимании.
Тут. Есть видео, для ленивых (как я).
Сначала заплатите за Друпал, как за видну - потом спрашивайте с CEO.
Можно было.
8.61 это 8-ка, просто в понимании Друпал 0-7, 8.5 это уже 13, а 8.6 - 14.
Как бы кому не было убого - миритесь.
Ну знаете, как бы то ни было, а ченджлоги надо читать. Причём по каждой цифре из версии.
Независимо от прочтения ченджлогов обновление продукта не должно приводить к крашу системы. Ну вот никак.
Опенсурс у вас это равноценно "бесплатный продукт"? С какого перепугу, если ты знаешь код системы - то ты юзаешь на свой страх и риск? Я вот помню кучу ЗАКРЫТЫХ продуктов с таким же условием - всякие мелкие проги в нулевых из инета.
Только никаким опенсурсом там и не пахло. Это были обычные exe-шники.
А это критическое условие? А если б друпал стоил бы 1 цент - можно было бы предъявлять претензии как у меня? То есть в итоге разница в 1 цент?
Хм, а 12 и 11 что было, а 10? Тогда тоже сносили таблицы?
Я бы хотел бы уточнить, мне лично никаких проблем не доставило, с чем мириться то? У меня нет на 8-ке проектов пострадавших, я не пострадал никоим образом, на самом деле подобное наплевательское отношение к пользователям разработчикам только выгоднее. Кроме того, если такое непотребство будет на семерке(может там тоже удалят пару таблиц) мне тоже только в плюс будет.
Только это не отменяет того факта, что так делать нельзя, я уже приводил пример винды, сделай так мелкософт вой был бы на всю галактику. А тут защищают...
Во-первых, тут нетривиальный случай - использование собственных запросов в обход рекомендованной практики использования api.
Попробуйте так в проприетарном софте поступить - и гарантии лишитесь, и иск ещё впаяют за реверс-инжиниринг.
И требовать от разработчиков поддерживать все недокументированные случаи использования кода - это как-то наивно.
Во-вторых, восьмерка - это энтерпрайз.
Всё, баста карапузики. Никаких drush up на проде.
Дев-тест-стейдж-прод, система контроля версий, мердж реквесты, код ревью, система деплоя, и никак иначе.
Короче не прочитали пункт пользовательского соглашения номер 8, подпункт 45 - сами виноваты. Мы же тут назвались новомодным словом, а поэтому нам ваши проблемы до одного места. Слово энтерпрайз видели? Так что пасть захлопнули и не вякаем.
Да что же тут нетривиального то?
Это что-то новенькое. Нельзя ли примеры привести, про какой такой софт вы речи ведете - ну чтобы в терминах не ошибаться? И как он там так же менял версии с крашем систем. Вы про какой софт то?
Да у всех разная реакция и это нормально.
Кто-то до сих пор находится в состоянии паники/стресса/потери_смысла_жизни, а кто-то через час после релиза 8.6.1 выкатил апдейты своих модулей...
ИМХО, топик для раздела "Курилка", а не "Решение проблем".
Пора завести новый раздел: "Создание проблем"))
Схема поля - это ответственность поля, к которой есть АПИ, который не менялся
Настоятельно рекомендую изучить. что является API и к чему будет обратная совместимость в минорных релизах
https://www.drupal.org/core/d8-bc-policy