Когда захотел написать грамотный обработчик для интеграции с 1с. Чтобы предложения были просто свойством со ссылкой на XML_ID основного элемента.))
Если интересно почему не стандартная интеграция, то она стандартная, просто в 1с это нифига не характеристики, и 1сник не стал делать их фейковыми предложениями.
А вообще план был, в том, чтобы поменять ИД инфоблока у записи, и добавить ссылку в нужное свойство. Вот только, инфоблоки 2.0 и да и у свойств свои идешники, а еще захотелось не все свойства копировать, а только те, которых нету и которые отличаются от родителя))) Ибо у них дофига свойств, для 200к товаров то) И это самые нужные свойства, которые выкинуть нельзя.
В общем тот еще изврат получился.
Ну и да... ORM при попытке изменить элемент чисто в таблице послал в стандартные компоненты, да еще и события потом отключать, чтобы в бесконечную рекурсию не уйти.
Так и живем. С основной сущностью платформы приходится взаимодействовать через голый sql. И для свойств, и для самих элементов и даже для юзеров порой. Ну либо заранее писать что-то сильно менее правильное, через старое ядро, в стиле создали копию элемента, потом удалили оригинал. Вот только потом пришлось бы еще переносить цены, склады и прочее. А так перекинул в другой иб, скопировав нужные свойства и поменяв им ид. И пожалуйста 200к товаров можно обработать менее чем за секунду внутри трех виртуалочек.
Если интересно почему не стандартная интеграция, то она стандартная, просто в 1с это нифига не характеристики, и 1сник не стал делать их фейковыми предложениями.
А вообще план был, в том, чтобы поменять ИД инфоблока у записи, и добавить ссылку в нужное свойство. Вот только, инфоблоки 2.0 и да и у свойств свои идешники, а еще захотелось не все свойства копировать, а только те, которых нету и которые отличаются от родителя))) Ибо у них дофига свойств, для 200к товаров то) И это самые нужные свойства, которые выкинуть нельзя.
В общем тот еще изврат получился.
Ну и да... ORM при попытке изменить элемент чисто в таблице послал в стандартные компоненты, да еще и события потом отключать, чтобы в бесконечную рекурсию не уйти.
Так и живем. С основной сущностью платформы приходится взаимодействовать через голый sql. И для свойств, и для самих элементов и даже для юзеров порой. Ну либо заранее писать что-то сильно менее правильное, через старое ядро, в стиле создали копию элемента, потом удалили оригинал. Вот только потом пришлось бы еще переносить цены, склады и прочее. А так перекинул в другой иб, скопировав нужные свойства и поменяв им ид. И пожалуйста 200к товаров можно обработать менее чем за секунду внутри трех виртуалочек.