Обновление 8.6.x > прощай, taxonomy_term_hierarchy ?

Главные вкладки

Аватар пользователя OldWarrior OldWarrior 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). В итоге, видимо, придётся перепиливать несколько модулей в сторону изменения запросов к БД.

У кого какие мысли на этот счёт?

Комментарии

Аватар пользователя adano adano 12 сентября 2018 в 23:45

OldWarrior wrote:

У кого какие мысли на этот счёт?

хз, в 7ке всегда использую taxonomy_get_parents или taxonomy_get_parents_all
Для 8ки, вроде так надо - тык

Аватар пользователя gun_dose gun_dose 12 сентября 2018 в 23:50
1

Полезно и ожидаемо. В старой структуре ссылка на родителя не содержалась в объекте термина, что само по себе идиотизм. И влекло за собой ряд глюков, например, невозможность получить родителя термина через jsonapi.

Аватар пользователя OldWarrior OldWarrior 13 сентября 2018 в 0:34

adano wrote:

...Для 8ки, вроде так надо - тык

Речь не о простом получении родителя(ей) через стандартные функции API, а о построении SQL-запросов в относительно сложном контексте (когда требуется поиск или SQL-выборка по многочисленным критериям). Когда, например, нужно получить в одном результате запроса одновременно и родителя и какие-то связанные с ним данные из других таблиц. Или, возможно, ещё и смежные термины под этим родителем. Да много таких случаев.

gun_dose wrote:

Полезно и ожидаемо. В старой структуре ссылка на родителя не содержалась в объекте термина, что само по себе идиотизм. И влекло за собой ряд глюков, например, невозможность получить родителя термина через jsonapi.

Согласен, что запросы через EntityQuery удобнее в большинстве случаев и теперь что-то будет несколько проще или по крайней мере - логичнее. Но насчёт ожидаемости - ну как-то нет, извините. Сколько кастомных модулей на текущий момент используют taxonomy_term_hierarchy (учитывая, что это был кратчайший/непосредственный путь программного получения структуры таксономии или построения SQL-запросов с учётом иерархии терминов)? Это всё теперь повлечёт повторный рефакторинг, отладку и т.п. Ну вообще - затронута таки одна из ключевых таблиц таксономии в архитектуре Друпала, это всё же не кеш и не поисковый индекс.

Было бы более понятно, если бы отказались от таблицы ещё где-то на инициальных релизах D8.

Аватар пользователя Niklan Niklan 13 сентября 2018 в 6:50
1

> Заказчик обновил ядро до 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.

> У кого какие мысли на этот счёт?

Изменение крайне полезное и правильное. Все были предупреждены, а кто не успел, решается быстро.

Per https://www.drupal.org/core/d8-bc-policy#schema, this is not a BC break:

While the database query API and schema API itself are stable, the schema of any particular table is not. Writing queries directly against core tables is not recommended and may result in code that breaks between minor versions.

Code using the Entity Query API does not need to be updated. Custom SQL queries using the taxonomy_term_hierarchy table will need to be updated, and are recommended to use the Entity Query API instead.

Ничего серьезного не случилось. Впрочем, как я уже написал, это минорная версия. Вообще, клиент на такие и не должен сам обновляться, ну или как минимум спросить разработчика, есть ли там что в 8.6.0 что может поломать сайт. Он же не читает ченджлоги, а если и читает, с высокой вероятностью он не в курсе, заденет его сайт конкретное упоминание или нет. Он так и на 8.7.0 обновится, что-то может развалиться, и на 8.8.0. Безопасно клиенту можно разрешить обновляться только в пределах патч версий, где апдейты уровня Drupal 7.

Аватар пользователя sas@drupal.org sas@drupal.org 13 сентября 2018 в 9:29

Хорошо бы скорей таксономию вообще замени на ентити релайшинсы для хэштегов в коробку. вьюсы встроили, хорошо бы и всю остальную модель привести к ER. Безобразие должно быть = единообразным.

Аватар пользователя gun_dose gun_dose 13 сентября 2018 в 9:52

OldWarrior wrote:

Сколько кастомных модулей на текущий момент используют taxonomy_term_hierarchy (учитывая, что это был кратчайший/непосредственный путь программного получения структуры таксономии или построения SQL-запросов с учётом иерархии терминов)?

Ну вот я, например, ни разу к этой таблице не обращался в кастомных модулях на восьмёрке. Как выше рассказали, переделать - 5 сек.

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:

Хорошо бы скорей таксономию вообще замени на ентити релайшинсы для хэштегов в коробку. вьюсы встроили, хорошо бы и всю остальную модель привести к ER.

Надо поковырять, вполне вероятно, что именно так и сделали. Поскольку в названии таблицы есть двойное подчёркивание, то это явно теперь поле, а не какое-то странное свойство. Тип поля надо смотреть в коде или через devel.

Аватар пользователя OldWarrior OldWarrior 13 сентября 2018 в 15:25

Niklan wrote:

20 января 2018 это изменение анонсировали. Тогда ещё вроде даже 8.5 не вышел. Всем дали привести всё в порядок. Оригинальный ишью так вообще с 2015 года. Но ишью это никто бы просто так и не нашел, но вот официальный ченджлог и уведомление больше чем полгода уже есть. Плюс упомянуто в релиз нотах 8.6.0.

Ну видимо - да, промухал я, каюсь. Или не обратил внимание когда-то. И заказчику тоже я дал благословение на апдейт - он не в первый раз делает самостоятельно. Я прочитал 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 в длительных операциях импорта разных типов данных, пришлось всё прогонять хотя бы на относительно небольших пачках данных).

В общем, морока. И это только в рамках одного проекта, на котором обнаружилась проблема.

Niklan wrote:

Если вы про поле parent. Оно с 8.6.0 теперь entity reference типа, а не самобытное. Именно поэтому и таблицы поменялись. Теперь таблица от entity_reference.

Да, о чём и речь. По крайней мере - очень близка, разве что вместо типичного для ссылок на термины 'target_ig' сделали 'parent_target_id'. В целом всё вроде в лучшую сторону, но могли бы таки ещё раз в релизе 8.6.1 сообщить об удалении старой таблицы, это всё-таки существенное изменение в общей механике таксономии.

Аватар пользователя Niklan Niklan 13 сентября 2018 в 17:39
2

Тут косяк именно в апдейте минорной версии не читая ченджлоги минорной версии, а не её патч версии, где эти апдейты и не нужно перечислять.

Минорные версии это 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%

Аватар пользователя Orion76 Orion76 14 сентября 2018 в 7:52

Ндаа.. поддых буквально..
Всего не упомнишь, при проверке ченджлогов, чего в "своих" модулях на ядро сильно завязано..

Хорошо бы для таких случаев где-то в модуле списочек иметь наименований сервисов, плагинов, таблиц бд и т.п., которые в модуле используются.

И команду драша или консоли, которая упоминание всего этого в ченнджлогах найдет и покажет..

Можно даже не конкретно "имена", а просто "слова" для поиска по ченджлогам , на которые стоит обратить внимание.

Аватар пользователя gun_dose gun_dose 14 сентября 2018 в 8:42

Вот кстати ещё один стимул использовать dependency injection вместо статического вызова сервисов - все зависимости как на ладони.

Аватар пользователя xakd xakd 14 сентября 2018 в 10:57

Ну вернуть старую табличку - косяки то исчезнут, а потом дописать синхронизацию, если уж так неохота новую использовать. Как временная мера

Аватар пользователя xakd xakd 14 сентября 2018 в 10:58

Но вообще конечно так не делают. Новая версия не должна кардинально старую перечеркивать, должен быть переходный период, когда обе таблицы бы существовали и работали корректно.

Аватар пользователя gun_dose gun_dose 14 сентября 2018 в 11:38
1

Это функции, классы, методы можно объявить deprecated и выпиливать потихоньку хоть годами. А таблицы - это структура данных. Одни данные не могут одновременно иметь две структуры, поэтому приходится делать так.

Но лично на мой взгляд, если аж 7 часов пришлось переделывать кастом, то тут явно что-то не так - слишком много кастомных запросов в базу, это явно не друпал-вэй.

Но это всё мелочи, я вам скажу. Вот я недавно обновлял один headless проект с 8.3.8 на 8.5 с чем-то. Плюс обновил весь контриб и вендоров. Вот там семью часами не обошлось))) хотя переделывать пришлось в основном по части реакта.

Аватар пользователя Orion76 Orion76 14 сентября 2018 в 19:24
1

Какую отсрочку не давай, все равно кто-то не успеет..
Тут надо как-то более системно проблему решать..

Аватар пользователя xakd xakd 14 сентября 2018 в 19:38

Помните сколько лет PHP поддерживало старые форматы баз, но уже вводила новые? Вот пример.
А прикинь они с твоей логикой - все, 4-я версия mysql(образно) не поддерживается, теперь только 5-я, а все кто не успел тот опоздал - мы написали, мол не обновляйтесь, угу.

Аватар пользователя xakd xakd 14 сентября 2018 в 17:57

gun_dose wrote:

Одни данные не могут одновременно иметь две структуры, поэтому приходится делать так.

Да конечно могут, что за ерунда. Можно было бы оставить и старую таблицу и писать туда те же данные, и всё.

Аватар пользователя fairrandir fairrandir 14 сентября 2018 в 18:34

xakd wrote:

Да конечно могут, что за ерунда

Но... Но... Но как? О_о. Одни и те же данные, которые хранятся в двух таблицах разом? И параллельно обновляются, и параллельно удаляются? И внешний интерфейс взаимодействия одинаковый?

Аватар пользователя xakd xakd 14 сентября 2018 в 19:28

И в чем проблема? Насколько я помню данные пишутся в итоге в одном месте. Просто будут автоматом ПИСАТЬСЯ в две таблицы. НО система забирать будет уже из новой, а те сторонние модули, которые со старой таблицей работают - из старой.
То есть запись просто параллельно идёт в обе таблицы. Да, будут проблемы с теми, кто пишет НАПРЯМУЮ в таблицы - но кто так делает с таксономией? Обычно же taxonomy_save() максимум идёт.

Аватар пользователя Orion76 Orion76 14 сентября 2018 в 20:12

@xakd
Писать данные сразу в две таблицы?
Поддерживать сразу 2 варианта реализации + поддерживать совместимость между этими вариантами?
Возможно какое-то время это можно, но потом начнутся проблемы движения "дальше"..

Я сильно сомневаюсь, что ради "ленивых" пользователей кто-то(из разработчиков этого функционала) будет жертвовать свое личное время .
Это понятно и логично..

Аватар пользователя xakd xakd 14 сентября 2018 в 20:14

Orion76 wrote:

Писать данные сразу в две таблицы?

Да, это элементарно. У нас пишет всего одна функция на весь Друпал.
Orion76 wrote:

Поддерживать сразу 2 варианта реализации + поддерживать совместимость между этими вариантами?

Какую ещё совместимость? Нет. Работаем мы с новой, но зато и старые модули, которые могут брать данные откуда привыкли. Чего тут особо поддерживать то?

Аватар пользователя Orion76 Orion76 14 сентября 2018 в 20:32

xakd wrote:

Чего тут особо поддерживать то?

Я и говорю, что "какое-то время это можно"..
Но потом один из вариантов начнет дополняться каким-то функционалом..
Во втором варианте, для совместимости это тоже надо будет делать..
потом во втором варианте, из-за специфичной структуры данных, повторить функции первого варианта станет невозможным..
и все..
начинаем с самого начала этого топика..

плюс не забываем, что Drupal это Open Source.
Т.е каждый его разработчик вносит свой вклад в соответствии с какой-то своей личной "необходимостью".
Возможно чешет свое чувство собственной значимости, а в большинстве случаев эта необходимость - скорее всего обусловлена его личным бизнесом (или как там еще он обеспечивает себя хлебом с маслом)

И ничего предъявить по этому поводу этим достойным людям никто не имеет права, просто потому что не имеет-)

Аватар пользователя xakd xakd 14 сентября 2018 в 20:34

Orion76 wrote:

Но потом один из вариантов начнет дополняться каким-то функционалом..

Да не скоро и начнет. А пока хотя все понимают, что старую таблицу уже использовать нельзя - и новые модули пишутся уже с новой таблицей, а старый обновляются, ибо ЕСТЬ КУДА ОБНОВЛЯТЬ. И месяцок у людей будет все переписать без обрушивания всей системы

Аватар пользователя Orion76 Orion76 14 сентября 2018 в 20:53

@xakd
Судя по этой информации, времени было достаточно,чтобы переписать свои модули

Niklan wrote:

20 января 2018 это изменение анонсировали. Тогда ещё вроде даже 8.5 не вышел. Всем дали привести всё в порядок. Оригинальный ишью так вообще с 2015 года. Но ишью это никто бы просто так и не нашел, но вот официальный ченджлог и уведомление больше чем полгода уже есть. Плюс упомянуто в релиз нотах 8.6.0.

сколько бы его (этого времени небыло), всегда найдется тот кто неуспел..

Поэтому я немного выше и предложил решать эту проблему системно, т.е. необходим некий иструмент, позволяющий вовремя обнаружить проблему с кастомном модуле, связанную с изменением его зависимостей.

Аватар пользователя xakd xakd 15 сентября 2018 в 8:28

Orion76 wrote:

Судя по этой информации, времени было достаточно,чтобы переписать свои модули

А как переписать, если новой таблицы ещё не было? Да отмазки все это. Так не делают. Я вон предложил аналогию с PHP - сколько тащили ради совместимости? А тут бах и типа разгребайте.
Это из той же оперы, что мол идите в гитхабе ищите что вам надо, какие обновления на сайте вышли - там же предупреждали, мелким шрифтом в некой теме на неудобном с непонятной структуре сайте по-английски полгода назад.

Аватар пользователя gun_dose gun_dose 15 сентября 2018 в 9:38

Напиши свой модуль, выложи на орг. Надо всего-то при установке модуля создать ту старую таблицу и заполнить данными из новой. И пару хуков в модуле, чтобы обновлять данные при сохранении термина.

Аватар пользователя gun_dose gun_dose 15 сентября 2018 в 15:12
1

Ничего не надо платить - это всё совершенно бесплатно. И как я описал выше, не надо патчить ядро, модуль простецкий - на пару хуков, даже без ООП.

Аватар пользователя Andruxa Andruxa 15 сентября 2018 в 9:41
5

Разрабам 100500 раз твердили: юзайте api, не надо лазить в базу напрямую. А раз уж полезли - будьте готовы к тому, что что-то может пойти не так.
Обновление не критическое, нет никакой нужды накатывать его в срочном порядке сразу на прод. Сначала вдумчиво курим diff, затем усиленно тестим то, что изменилось, и уже затем выкатываем это в прод.

Аватар пользователя xakd xakd 15 сентября 2018 в 14:54

Andruxa wrote:

Разрабам 100500 раз твердили: юзайте api, не надо лазить в базу напрямую. А раз уж полезли - будьте готовы к тому, что что-то может пойти не так.

А что ж высшие разрабы то стали менять структуру таблиц, если она была такая идеальная, юзай только API? Может как раз не хватало функционала API и приходилось напрямую лезть, что заставило в итоге разрабов переработать весомую часть таксономии?
Andruxa wrote:

Обновление не критическое, нет никакой нужды накатывать его в срочном порядке сразу на прод. Сначала вдумчиво курим diff, затем усиленно тестим то, что изменилось, и уже затем выкатываем это в прод.

Да понятно, виноваты сами пользователи, что обновились. Представьте что винду обновили, а она крашнулась? И тут выходят люди, которые говорят - вы че, не читали что ли,что в обновлении, там всего страниц то 10, че обновлялись то? Сами виноваты, Микрософт не причем. Читать надо пользовательское соглашение, там в пункте 18 в подпункте 45 прямо указано, что сначала надо прошерстить весь софт на предмет несовместимости, а потом уж обновлять. А уж если автообновление поставили - то вообще сами виноваты.
Такая ваша позиция как я понимаю.

Аватар пользователя xakd xakd 15 сентября 2018 в 15:33

Просветите плиз, в чем у меня недопонимание? Опенсурс исключает ответственность за продукт?

Аватар пользователя bumble bumble 15 сентября 2018 в 15:41
3

Все элементарно до невозможности.
Под любой маской "LTS-enterprise-mega-supporting" находится единственная истина:

  • НИКТО
  • НИКОМУ
  • НИЧЕГО
  • НЕ ДОЛЖЕН

Каждый ответственен только за свой продукт.
Мы все используем результаты работ других людей, реализовавших свои идеи в коде, под их нужды.
Все что не нравится - реализуется самостоятельно.
При малейших признаках недовольства - перечитываем мантру, написанную капсом.

Аватар пользователя xakd xakd 15 сентября 2018 в 16:08

Мы все используем результаты работ других людей, реализовавших свои идеи в коде, под их нужды

Эээ нет, это продукт они РАСПРОСТРАНЯЮТ, это не под ИХ нужды - он позиционируется как продукт для НАШИХ нужд. Тоже мне бессребреников нашел.
Хотя вы интересно подменяете тему разговора о деловой( в данном случае программистской, не знаю, этикой разработчика) этике юридическими аспектами - мол, юридически они ничего не должны, а значит рот закройте.

Аватар пользователя bumble bumble 15 сентября 2018 в 16:14

Если прочитать не по диагонали, то я не "рты закрываю", а объясняю философию открытого ПО - юзаешь на свой страх и риск, в том виде как дают, если хочешь - переделываешь на то, что нужно тебе.

Юридические там, или мета-физические аспекты - не помогут, если не понять суть.

Аватар пользователя xakd xakd 15 сентября 2018 в 15:59

bumble wrote:

Каждый ответственен только за свой продукт.

Кроме разрабов Друпала. Они даже за него не ответственны. Ужас.

Аватар пользователя xakd xakd 15 сентября 2018 в 16:01

Я конечно все понимаю, но с каких пор бесплатность продукта освобождает от ответственности за неприятности и проблемы при его использовании? Что это за извращённое понятие опенсурса?

Аватар пользователя bumble bumble 15 сентября 2018 в 16:09

Какие такие неприятности??
Я вот, не лез к иерархии терминов, и нет у меня неприятностей никаких. Все как часики!

Аватар пользователя xakd xakd 15 сентября 2018 в 19:23

Да у меня тоже, но мы разве от своей колокольни тут пляшем? Мы тут обсуждаем, правильный ли подход у компании, которая выпускает drupal, поступать подобным наплевательским способом.
Как по мне - идиотский и свинский. Мол, мы там полушепотом сказали в ЯНВАРЕ, что КОГДА-НИБУДЬ в 8.6* КАКОЙ_ТО ВЕРСИИ НЕИЗВЕСТНО КОГДА мы удалим важную таблицу в Друпал. А вы пока думайте КАК мы это сделаем, на что заменим, а если не придумали правильно - сами мудаки и жрите что дают, ибо "НИКТО НИЧЕМУ НИЧЕГО НЕ ДОЛЖЕН", опенсурс же.
Боже мой, и вы поддерживаете такой подход к продукту?

Аватар пользователя xakd xakd 16 сентября 2018 в 10:49

А, ну перешли в формальный стиль разговора. Типа не прочитали Пользовательское соглашение - ваша проблема. Помнится даже в Южном парке была про это серия прекрасная

Аватар пользователя OldWarrior OldWarrior 15 сентября 2018 в 17:31

Andruxa wrote:

Разрабам 100500 раз твердили: юзайте api, не надо лазить в базу напрямую.

bumble wrote:

Я вот, не лез к иерархии терминов, и нет у меня неприятностей никаких. Все как часики!

В принципе (применительно к моему случаю), ответ уже прозвучал:

xakd wrote:

...Может как раз не хватало функционала API и приходилось напрямую лезть...

Насколько было возможным - придерживались пресловутого drupal-way.
Но исходные вводные (структура данных, полей и сущностей) и общий характер функционала были таковы, что возможностей Entity API и Entity Query API было как минимум недостаточно. Задачи были нетривиальные и довольно сложные - главным образом импорт/синхронизация данных из различных внешних API с выборкой из нескольких буферных/промежуточных таблиц сырых нативных данных.

Т.е. - можно было, конечно, долго пилить и искать труЪ-друпал-вэй (сомневаюсь, что это в итоге привело к ожидаемому заказчиком результату), а можно было выбрать допустимый компромисс между бюджетом и временем. Да и, в конце концов, модули писались под КОНКРЕТНЫЙ проект, не для широкого применения. Заказчик в общем-то тоже знал об этом и совсем не возражал, главное - чтобы была решена задача.

Аватар пользователя Andruxa Andruxa 15 сентября 2018 в 17:44

OldWarrior wrote:
Задачи были нетривиальные и довольно сложные

Даже не пытался критиковать это решение. Действительно, бывают случаи, когда средств api недостаточно.
Речь о том, что такие сложные решения требуют особого внимания.

Аватар пользователя bumble bumble 15 сентября 2018 в 18:21
1

Блин...
Да, понимаю, "ннада именно так, но так нет в API - напишу ка". Все это проходили.
Но чего теперь на релизеров бочку катить то? Сами пишем - сами свои же поделки поддерживаем, разве не такая логика?

Никита выше писал, что это обновление равносильно переезду с 6ки на 7ку - какие тут могут быть возражения и бек-саппортинг?

Никто же не ныл когда структуры полей (CCK) в ядро поместили и поламали всю совместимость в 7ке. А тут вдруг "негодяи и мерзавцы" - слишком мало предупреждений написали... Есть же возможность на 8.5.* оставаться - там не нужно переписывать ничего.

Аватар пользователя xakd xakd 15 сентября 2018 в 19:18

bumble wrote:

объясняю философию открытого ПО - юзаешь на свой страх и риск, в том виде как дают, если хочешь - переделываешь на то, что нужно тебе

Вы серьезно? Это в вашем понимании опенсурс?
bumble wrote:

Никита выше писал, что это обновление равносильно переезду с 6ки на 7ку - какие тут могут быть возражения и бек-саппортинг?

Это где такое было указано? Или это очередная постфактум отмазка? Это счас выйдет обновление у винды, которая крэшанет все системы - а сео выйдет и скажет - мол, это считай 11-я система, мы никому не говорили громогласно, но кто не понял извините?
Да позорище это, а не отмазки.
bumble wrote:

Никто же не ныл когда структуры полей (CCK) в ядро поместили и поломали всю совместимость в 7ке.

А знаете почему? Потому что нельзя было обновиться с 6-ки на 7-ку иначе как ручками все переделывая. То есть берясь за обновление 6-7 ни у кого не было недопонимая, что они мол на 6.29 обновляются одной кнопкой. Не надо тут рассказывать, что 8.61 это не 8-ка - выглядит убого.

Аватар пользователя Semantics Semantics 15 сентября 2018 в 20:17

А знаете почему? Потому что нельзя было обновиться с 6-ки на 7-ку иначе как ручками все переделывая. То есть берясь за обновление 6-7 ни у кого не было недопонимая, что они мол на 6.29 обновляются одной кнопкой. Не надо тут рассказывать, что 8.61 это не 8-ка - выглядит убого.

Ну так никто не запрещает сидеть на 8.5.х, зачем сразу на 8.6 лезть?

Аватар пользователя bumble bumble 15 сентября 2018 в 19:29

xakd wrote:

Это в вашем понимании опенсурс?

Да. Уверен, не только в моем понимании.

xakd wrote:

Это где такое было указано?

Тут. Есть видео, для ленивых (как я).

xakd wrote:

выйдет обновление у винды

Сначала заплатите за Друпал, как за видну - потом спрашивайте с CEO.

xakd wrote:

нельзя было обновиться с 6-ки на 7-ку

Можно было.
8.61 это 8-ка, просто в понимании Друпал 0-7, 8.5 это уже 13, а 8.6 - 14.
Как бы кому не было убого - миритесь.

Аватар пользователя xakd xakd 16 сентября 2018 в 10:51

Независимо от прочтения ченджлогов обновление продукта не должно приводить к крашу системы. Ну вот никак.

Аватар пользователя xakd xakd 16 сентября 2018 в 11:07

bumble wrote:

Да. Уверен, не только в моем понимании.

Опенсурс у вас это равноценно "бесплатный продукт"? С какого перепугу, если ты знаешь код системы - то ты юзаешь на свой страх и риск? Я вот помню кучу ЗАКРЫТЫХ продуктов с таким же условием - всякие мелкие проги в нулевых из инета.
Только никаким опенсурсом там и не пахло. Это были обычные exe-шники.
bumble wrote:

Сначала заплатите за Друпал, как за видну - потом спрашивайте с CEO

А это критическое условие? А если б друпал стоил бы 1 цент - можно было бы предъявлять претензии как у меня? То есть в итоге разница в 1 цент?
bumble wrote:

8.61 это 8-ка, просто в понимании Друпал 0-7, 8.5 это уже 13, а 8.6 - 14.

Хм, а 12 и 11 что было, а 10? Тогда тоже сносили таблицы?
bumble wrote:

Как бы кому не было убого - миритесь.

Я бы хотел бы уточнить, мне лично никаких проблем не доставило, с чем мириться то? У меня нет на 8-ке проектов пострадавших, я не пострадал никоим образом, на самом деле подобное наплевательское отношение к пользователям разработчикам только выгоднее. Кроме того, если такое непотребство будет на семерке(может там тоже удалят пару таблиц) мне тоже только в плюс будет.
Только это не отменяет того факта, что так делать нельзя, я уже приводил пример винды, сделай так мелкософт вой был бы на всю галактику. А тут защищают...

Аватар пользователя Andruxa Andruxa 16 сентября 2018 в 11:31
1

Во-первых, тут нетривиальный случай - использование собственных запросов в обход рекомендованной практики использования api.
Попробуйте так в проприетарном софте поступить - и гарантии лишитесь, и иск ещё впаяют за реверс-инжиниринг.
И требовать от разработчиков поддерживать все недокументированные случаи использования кода - это как-то наивно.

Во-вторых, восьмерка - это энтерпрайз.
Всё, баста карапузики. Никаких drush up на проде.
Дев-тест-стейдж-прод, система контроля версий, мердж реквесты, код ревью, система деплоя, и никак иначе.

Аватар пользователя xakd xakd 16 сентября 2018 в 20:53

Andruxa wrote:

Во-вторых, восьмерка - это энтерпрайз.

Всё, баста карапузики. Никаких drush up на проде.

Дев-тест-стейдж-прод, система контроля версий, мердж реквесты, код ревью, система деплоя, и никак иначе.

Короче не прочитали пункт пользовательского соглашения номер 8, подпункт 45 - сами виноваты. Мы же тут назвались новомодным словом, а поэтому нам ваши проблемы до одного места. Слово энтерпрайз видели? Так что пасть захлопнули и не вякаем.
Andruxa wrote:

Во-первых, тут нетривиальный случай - использование собственных запросов в обход рекомендованной практики использования api.

Да что же тут нетривиального то?
Andruxa wrote:
Попробуйте так в проприетарном софте поступить - и гарантии лишитесь, и иск ещё впаяют за реверс-инжиниринг.

Это что-то новенькое. Нельзя ли примеры привести, про какой такой софт вы речи ведете - ну чтобы в терминах не ошибаться? И как он там так же менял версии с крашем систем. Вы про какой софт то?

Аватар пользователя adano adano 16 сентября 2018 в 22:16

Да у всех разная реакция и это нормально.

Кто-то до сих пор находится в состоянии паники/стресса/потери_смысла_жизни, а кто-то через час после релиза 8.6.1 выкатил апдейты своих модулей...

ИМХО, топик для раздела "Курилка", а не "Решение проблем".

Аватар пользователя andypost@drupal.org andypost@drupal.org 19 сентября 2018 в 13:05
2

Схема поля - это ответственность поля, к которой есть АПИ, который не менялся

Настоятельно рекомендую изучить. что является API и к чему будет обратная совместимость в минорных релизах

https://www.drupal.org/core/d8-bc-policy