Как работает связывание конфигурируемых продуктов в magento?
Избавиться от троллинга, связывая конфигурируемые продукты с их простыми аналогами? Давайте объясним, как Magento link'em ... и почему он иногда не работает, как ожидалось.
Первое, что нужно понять, это то, как приложение управляет постоянством данных. Как и ожидалось, ссылки хранятся в базе данных. Думал, что это было в catalog_product_relation ? Ты был неправ. Должно быть слишком просто уважать дух Magento:)
отношение_продукта_каталога к каталогу_продукта_каталога_ * таблицы
Я не скажу catalog_product_relation бесполезно - на самом деле, оно обязательно есть для чего-то. Но с версии 1.5+ ссылки хранятся не там, и я не могу объяснить, для чего она предназначена.
Первый шаг
Первым шагом процесса связывания является определение настраиваемых атрибутов настраиваемого продукта. Предположим, мы создаем новый настраиваемый продукт из набора атрибутов, имеющих несколько атрибутов global-select.
Если вы попытаетесь получить доступ к вашему настраиваемому продукту, приложение спросит вас, какой из них следует использовать в качестве настраиваемых атрибутов, в форме, использующей список флажков, связанных с каждым атрибутом. Выбрав некоторые из них и сохранив свой продукт, вы вставляете в catalog_product_super_attribute строку по атрибуту (связь между идентификатором продукта и атрибутом).
Второй шаг
Второй шаг - это связывание себя с соответствующими простыми продуктами. Этот шаг немного сложнее, потому что он подразумевает некоторые проверки содержимого базы данных, которые мы подробно рассмотрим ниже. Несколько правил, о которых следует помнить:
- только продукты с тем же атрибутом, что и текущий настраиваемый продукт
- опции должны быть определены для настраиваемого атрибута
- для данной настраиваемой комбинации атрибутов можно связать только одно простое
- simple может быть связано с любым количеством настраиваемых параметров
Тогда, что произойдет, когда мы перейдем на вкладку наших настраиваемых продуктов? Не бойтесь не видеть ни одного вашего простого соответствующего продукта в отображаемом списке - его фильтр по умолчанию настроен на отображение только уже связанных продуктов. Вот что происходит за сценой:
- приложение проверяет таблицу catalog_product_super_attribute и возвращает каждый соответствующий идентификатор атрибута, определенный там для текущего продукта (наши настраиваемые атрибуты)
- из них пойдет проверка eav_attribute , чтобы получить некоторые сведения о них - в каких из них backend_type , что является наиболее важной частью этого объяснения
- параллельно проверяется также таблица catalog_product_super_link . Любой продукт, связанный с current_product, является потенциальным связанным продуктом
- для каждого атрибута приложение проверяет, существует ли значение в catalog_product_entity_ {backend_type} для каждого потенциально связанного продукта. Обратите внимание, что если для данного продукта не существует значения, оно не будет проверено ни как потенциальная ссылка, ни как эффективная, даже если оно уже было связано (ниже мы увидим, что это означает для создания атрибута).
Чтобы возобновить, только продукты с действительным значением могут быть озвучены и эффективно связаны. Обратите внимание, что все комбинации должны иметь допустимые значения - если какой-либо атрибут настраиваемого атрибута отсутствует, игра окончена, у вас не будет никакой связи между вашим простым продуктом и его настраиваемым аналогом.
Мы должныЯ думаю, что все в порядке, и все пойдет прямо сейчас, так как мы знаем, как все работает в базе данных. Это правда, если вы всегда создаете свои атрибуты из бэк-офиса приложения. Но так как атрибуты сценариев - очень распространенный способ продолжения, вы очень похожи на этот второй случай, который подразумевает потенциальную ОГРОМНУЮ проблему.
Программно созданные атрибуты и ... Какого черта!?! Этот атрибут имеет изменение типа бэкэнда!
- Редактирование заметки: этот случай эффективно происходит при использовании исходной модели eav / entity_attribute_source_table
Это проблема, через которую я лично столкнулся. Если вы проверите атрибуты внутренних моделей в базе данных (только для выбранных атрибутов - нам не важно, какие из них нельзя использовать в качестве настраиваемых), вы увидите несколько varchar, некоторые int ... Короче говоря, несколько, и мы могли бы по праву рассчитываю на любую из них работ.
И они так и делают. Поскольку вы не решаете добавить опцию к своему атрибуту из бэк-офиса или что-либо еще, для чего требуется нажать кнопку «сохранить» на странице атрибута.
Суть в том, что когда вы сохраняете свой атрибут, Magento, в его великой благости, спрашивайте себя, какой тип атрибута вы просите его сохранить. Дело в том, что прежде всего это выбор. И выбор имеет варианты. И у опций есть id. Какие значения будут помещены в catalog_product_entity_ {backend_type} , в любом случае. В этом случае метка просто должным образом игнорируется (она хранится в правильной таблице и не влияет ни на что). Используется только идентификатор.
А что нам ожидать от Magento :)?
Он просто систематически меняет тип бэкенда атрибута на int.
Итак, если у вас есть продукты, которые раньше были связаны, и их больше нет, то посмотрите таблицы catalog_product_entity_ {backend_type} и таблицу eav_attribute - сравните тип бэкэнда, найдите значения в каждой таблице значений ... Если вы найдете их в таблице, которая не соответствует, вы получите свою проблему. У вас есть несколько способов исправить проблему, вот оба я нахожу себя (и я действительно не рекламирую первый , который я поставил только для целей объяснения).
Первый способ: вернуть тип бэкенда ( Dirty Trick)
Он изменился на int? Не волнует Верни это к тому, что ты хочешь, чтобы это было.
Почему это грязно : потому что вы хотите, чтобы ваш пользователь мог обновлять его атрибуты, когда он хочет. Например, если вы измените тип бэкэнда на varchar, при любом изменении метки в бэк-офисе для параметра будет выполнен откат до int, поскольку он будет сохранен.
Второй способ: давайте все исправим! (Правильная вещь)
Вы можете пройти через эту ... плохую ситуацию с небольшим количеством MySQL без ущерба для вашей базы данных. Но, пожалуйста, сначала брось это. Тогда вам потребуется 4 шага:
- проверьте, что у вас еще нет данных в catalog_product_entity_int таблица
- дублирует строки текущей ... сущности {атрибута таблицы до таблицы ..._ entity_int с помощью оператора INSERT / SELECT ( этот запрос может быть немного длинным)
- обновите ваши настраиваемые атрибуты (не все ваши атрибуты, ТОЛЬКО те, которые вы знаете и создали, и которые используете для установки настраиваемых продуктов), чтобы установить для их типа бэкэнда значение int (и больше никогда не делать что-либо еще для настраиваемых выборов :))
- удалите все записи, соответствующие атрибуту в таблице ..._ entity {attribute} , которые вы больше не будете использовать (он может делать довольно много записей, поскольку вы можете получить много продуктов, если получите много вариантов)
Вот некоторые сценарии MySQL, соответствующие этим шагам. Предположим, у вас есть при запуске список соответствующих кодов атрибутов:
Проверить существующие записи в объекте int на предмет заданного списка кодов атрибутов
-- Check existing entries to not duplicate
SELECT ea.attribute_code,
count(*)
FROM eav_attribute as ea
INNER JOIN catalog_product_entity_int as cpei
ON ea.attribute_id = cpei.attribute_id
WHERE ea.attribute_code IN(
{attributeCodesList}
)
GROUP BY ea.attribute_code
Дублированныйзаписи из таблицы entity_varchar (например) в entity_int для заданного списка кодов атрибутов
-- Duplicating missed selects from varchat entity table to int
INSERT INTO catalog_product_entity_int (entity_type_id, attribute_id, store_id, entity_id, value)
SELECT cpev.entity_type_id,
cpev.attribute_id,
cpev.store_id,
cpev.entity_id,
cpev.value
FROM eav_attribute as ea
INNER JOIN catalog_product_entity_varchar as cpev
ON ea.attribute_id = cpev.attribute_id
WHERE ea.attribute_code IN(
{attributeCodesList}
)
Обновите атрибуты, чтобы никогда больше не возникало проблем!
-- Update missed select attributes from varchar backend type to int one
UPDATE eav_attribute as ea
SET ea.backend_type = 'int'
WHERE ea.attribute_code IN (
{attributeCodesList}
)
Удалите больше не используемые записииз вашей базы данных
-- Kill old varchar in varchar entity table
DELETE FROM catalog_product_entity_varchar
WHERE attribute_id IN (
SELECT ea.attribute_id
FROM eav_attribute as ea
WHERE ea.attribute_code IN (
{attributeCodesList}
)
)
Надеюсь, это поможет всем тем, кто не может сделать так, чтобы их сопутствующие товары появились, чтобы получить хитрость!