ошибка 1442, триггер

[iceman]

ошибка 1442, триггер

DELIMITER |

  CREATE
  TRIGGER racms_trigger_catalog_content BEFORE DELETE
  ON racms_modules_content_catalog

  FOR EACH ROW BEGIN
    UPDATE racms_modules_content_catalog SET parent_id = 0 WHERE parent_id = OLD.id;
  END;

| DELIMITER ;

вот таблица

CREATE TABLE `racms_modules_content_catalog` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `catalog_name` varchar(255) NOT NULL,
  `default_cat` tinyint(1) unsigned default '0',
  `position` int(10) unsigned NOT NULL default '0',
  `parent_id` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

хочу чтобы при удаление определенной записи, он устанавливал parent_id на 0 у таблиц у которых parent_id равнялся id удаляемой записи...

вот только происходит ошибка при удаление... в мануале про синтаксис триггера мало что есть...

mysql 5.1

Can't update table 'racms_modules_content_catalog' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.

-~{}~ 13.08.08 09:17:

хоть и убрал
UPDATE racms_modules_content_catalog SET parent_id = 0 WHERE parent_id = OLD.id;

всеравно происходит ошибка при удаление записи с таблицы

 

[Dl]

Я бы сделал другим запросом.
И смысл в update, если таких id больше не будет?

 

[iceman]

удаляем ID например 7, и у всех суб-каталогоов у которыч parent_id равнялся 7, делаем parent_id = 0

-~{}~ 13.08.08 11:21:

я так понял, триггер в mysql не может работать с данной таблицей к которой он прикручен.

 

[Dl]

Вобще логично, что parent_id = 0 означает верхний уровень каталога...

 

[iceman]

ну вот, тригер и делает так, без тригера parent_id = 7 так бы и осталось. но каталога с id = 7 уже нету...

-~{}~ 13.08.08 11:32:

я вынес id и parent_id в отдельную таблицу и просто назначил FK ON DELETE CASCADE

-~{}~ 13.08.08 12:23:

теперь вопрос:
в новой таблицы так:
-----------------------
id | fk_catalog | fk_catalog_parent
-----------------------
1 | 1 | 2
2 | 3 | 1
3 | 4 | 3

как одним запросом, если можно, отследить дерево каталога 4

т.е. тут 2 - 1 - 3 - 4

 

[crocodile2u]

iceman
Да, если ИнноДБ - то внешний ключ даже в принципе лучше в этом случае.

Для МайИсам задача с триггером, видимо, нерешаема.

Теперь про выборки одним запросом

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

Альтернативы:
1. Не хранить дополнительных полей, использовать классичекий список смежности (ID-ParentID), но интенсивно использовать кэширование. Потенциально можно получить много запросов к базе, но как только закэшировали - все, мы в дамках.
2. Использовать другой способ хранения дерева, например, Вложенные Множества (подходит, если дерево "квазистатическое", то есть редко меняется) или Материализованные Пути.