Писал импорт каталога для одного сайта. Начал тестировать и удивился сильным тормозам: скорость примерно в 1 элемент инфоблока в секунду. Начал было думать, что хостинг никудышный, но нет. При ковырянии кода напоролся на такое вот "замечательное" решение из маркетплейса, именуемое "Список 2.0". http://marketplace.1c-bitrix.ru/solut...ipol.auen/ Убивает обмен моментально ))
Сортировка вариантов списка происходит на КАЖДУЮ установку значения элемента инфоблока. В результате этого "гениального" решения, при N вариантах значений списка и M товаров, количество запросов на обновление одного такого свойства у всех товаров будет не M, а M*N! Точнее даже не M*N, а M*N*2, т.к. еще есть дополнительный запрос сброса кэша по тэгу. А если таких свойств несколько (у клиента их было с десяток), то будет полный бздец. В общем, ребята, не надо так делать. При разработке свойств учитывайте, что есть не только интерфейсная часть свойства в админке, но и разного рода взаимодействия через API. Всем доброго утра понедельника
Антон Пилецкий , а вы написали авторам данного решения? Указали им на их ошибку? В общем, какие действия вы предприняли до того как появился этот пост?
при всем уважении, тут в сообществе некоторых даже и не гениев коробит, когда их достают по ночам То, что вы ночами ковыряетесь - это ваше право и хобби, которые никак не являются законодательством для других. Я спрашивал, какие действия в отношении взаимодействия с авторами решения вы предприняли.
Для статистики, сколько времени прошло между вашим запросом и ответом разработчиков и появлением данного поста?
Коваленко Алексей написал: Для статистики, сколько времени прошло между вашим запросом и ответом разработчиков и появлением данного поста?
Я не стал дожидаться их ответа. И не уверен, что они ответят. Да, может это и неэтично, и всё такое. Но мне, честно, фиолетово. Если, например, в моих модулях (особенно платных) вдруг обнаружится такой ужасный баг, я желаю чтобы мне об этом сообщили в любой форме, даже публичной - это только простимулирует быстрое решение проблемы. Если автор данного решения исправит ошибку оперативно - это будет ЖИРНЫЙПЛЮС его решению и его команде разработчиков. Пост является скорее предупреждением. Клиентам - от покупки данного модуля, пока авторы не исправят ошибки. Разработчикам - чтобы не делали подобных ошибок.
Не знакома с разработчиками данного решения, но думаю, что руководителю их команды будет очень неприятно читать данный пост (если он вообще заходит сюда и читает сообщество). Говнокод может родиться у любой, даже очень хорошей команды, и у каждой команды есть определенный план и регламент времени на развитие готового решения. Покажите мне хоть одно решение из маркетплейса, которое идеально - я найду, что в нем обругать и опплевать. Но не стала бы поливать говном разработчиков готового решения, даже платного, потому что писать самому с нуля или допиливать готовое решение - это выбор каждого внедренца. Хороший внедренец сделает конфетку из плохого готового решения, а публично ругают чужой код плохие внедренцы.
Пилецкий Антон, ну вообще, данное решение я бы тоже удалила, и даже, наверное, прокляла бы разработчиков, потому что когда сторонний модуль убивает обмен с 1С, я разработчиков такого модуля проклинаю. Но лично. А там уже исправят или нет - их проблемы.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».