вы типа то решение не обновляли вообще и просто фигачите новое уже на втором сайте?
Не совсем понял вопрос. Сама логика объединения товаров в группы именно в этом случае была одинаковой. Если вы имеете в виду ломалось ли что-то после обновления, то нет - сравнение происходило либо по строке, либо по правилу.
Я присоединюсь к Антону. Задачу я понял, нормальных путей решения пока нет, но то, что вы намертво завязаны на тестирование обновлений (изменение внутренней структуры инфоблоков и товаров) - несомненно.
Если честно, хоть убейте, не могу понять ваших опасений) С точки зрения обновлений SQL, действительно, кажется менее стабильным решением, хоть напрямую названия полей не задавались. Полагаю, ORM эту проблему решит. Если речь о внутренней структуре каталогов (свойства, значения свойств, вычисляемые свойства и т.д.), то здесь все нужные связи задает сам администратор, менеджер или программист. Связь устанавливается на уровне сущности с выбранным фильтром и primary полем: значения элемента 1-го инфоблока = значения элемента 2-го инфоблока, свойство к свойству, цена к цене, остатки на складе 1-го товара ко 2-му. Я могу описать принцип работы более подробно, если интересно. Но даже в случае какого-то сверх критичного изменения при обновлении или в структуре данных, лог событий отобразит ошибки на этой связи без фактического изменения.
Да у меня нет никаких опасений. Я просто насмотрелся на тикеты и вопросы типа "я сделал так-то, все сломалось". Проект ваш, риски ваши, решение тоже за вами. Я просто подчеркнул, что при этом подходе вам нужно отслеживать изменения ядра. А они бывают рано или поздно, вот и все.
Отслеживание изменений ядра - это само собой. Я лишь хочу понять, есть ли в этой концепции что-то такое, чего я мог не учесть на данный момент) Как один из примеров - некоторые события orm заблокированы. Что-то будет всплывать и будут ошибки.
Придет еще кто-то с запросом "я создавал такую-то сущность в инфоблоках, все сломалось" - заблокирую еще таблеты. Других способов борьбы с этой проблемой за долгие годы не обнаружено. Все как в анекдоте про туннель, поезд и его пасажиров.
Правильно ли я понял, что ORM, в большей степени, подходит для выборки данных, в то время как для изменения или удаления рекомендуется использовать стандартное api из-за набора внутренних связей, к примеру доступность товара по количеству его торговых предложений?
В принципе - да. Встречаются таблеты (классы чего-тоTable), где бизнес-логика зашита изначально (не было старых классов). Но в массе своей это низкоуровневое api. Подход следующий - если есть класс над таблетом - использовать для модификации данных его (примеры: Order и OrderTable, Basket и BasketTable). Инфоблоки и товары здесь стоят особняком, т.к. этой бизнес-логики слишком много. Даже в объектном orm инфоблоков хватает ограничений (есть страничка со списком в учебном курсе). Поэтому даже выборки через orm там с оговорками.
Я понял о чем вы говорите. В целом, эта ситуация возможна и на разных проектах, даже на одной редакции и версии. Буду по возможности использовать стандартное api. Спасибо!
Обсуждают сегодня