PHP DM Gate v0.9 » Дерево в БД - проблема при удалении узла <span class="vd">[D7, FB 1.5.]</span>

trubin © (01.05.08 21:35) [0]

Здравствуйте, появилась вот проблемка:

имеется таблица в БД, в которой храниться древовидная структура, конкретнее эта таблица используется для хранения элементов файловой

системы. Кусок DDL:

CREATE TABLE FILES(
ID NUMERIC(18,0), /*первичный ключ*/
PARENT_ID NUMERIC(18,0), /*ключ родителя*/
CHILD_COUNT INTEGER, /*количество потомков*/
...
);

имеется триггер after delete:

CREATE TRIGGER TR_AD_FILES_0 FOR FILES ACTIVE AFTER DELETE POSITION 0
AS
BEGIN
/*УМЕНЬШАЕМ СЧЕТЧИК ПОТОМКОВ У РОДИТЕЛЯ*/
IF (OLD.PARENT_ID > 0) THEN
UPDATE FILES F
SET F.CHILD_COUNT = F.CHILD_COUNT - 1
WHERE F.ID = OLD.PARENT_ID;
/*УДАЛЯЕМ ПОТОМКОВ ДАННОГО ЭЛЕМЕНТА*/
DELETE FROM FILES F
WHERE F.PARENT_ID = OLD.ID;
END
;

ПРОБЛЕМА: при удалении узла дерева имеющего множество потомков на многих уровнях вложенности выскакивает ошибка:
"Too many concurrent executions of the same request"

Это, я так понимаю из-за рекурсивного вызова триггером самого себя. Как бы этого избежать? Не хочется городить какие-то сложные

алгоритмы для удаления. Посоветуйте.

<Цитата>
PEAKTOP © (01.05.08 22:33) [1]

> "Too many concurrent executions of the same request"

Это где-то у тебя на триггере или ХП сервер рекурсивно в бесконечный цикл уходит. По умолчанию - не более 1000 уровней рекурсии положено.

Или данные в таблице корявые, или еще где-то триггер есть, который ты не привел.

<Цитата>
trubin © (01.05.08 23:48) [2]

> Или данные в таблице корявые, или еще где-то триггер есть,
> который ты не привел.

Триггер на delete один во всей базе

<Цитата>
DrPass © (02.05.08 02:12) [3]

Поставь его на before delete

<Цитата>
MsGuns © (02.05.08 02:43) [4]

Групповое удаление на само по себе опасная штука, а если оно еще зашито в триггер, то неприятности обеспечены

<Цитата>
trubin © (02.05.08 10:55) [5]

> Поставь его на before delete

Сразу пробовал - та же картина

> MsGuns © (02.05.08 02:43) [4]
> Групповое удаление на само по себе опасная штука, а если
> оно еще зашито в триггер, то неприятности обеспечены

Это я понимаю, вот только сколько не гуглил, книжки не листал особо не помогает...

Буду думать :)

<Цитата>
trubin © (03.05.08 18:55) [6]

> PEAKTOP © (01.05.08 22:33) [1]

Ты прав, проблема была в данных. Но удаление потомков из триггера все-таки убрал - засунул в рекурсивную ХП.

<Цитата>
Prohodil Mimo © (03.05.08 20:39) [7]

а ON DELETE CASCADE не помогает или это хуже триггера?

<Цитата>
PEAKTOP © (03.05.08 23:14) [8]

> а ON DELETE CASCADE не помогает или это хуже триггера?
На версионнике ? Еще раз повторяю: не на блокировочнике, а на версионнике FOREIGN KEY на саму себя ?

> проблема была в данных
Деревья просто снятся но ночам :) в кошмарах ...

<Цитата>
Prohodil Mimo © (04.05.08 14:28) [9]

PEAKTOP © (03.05.08 23:14) [8]
а почему нет? всё же происходит в одной транзакции.
С деревьями в FB не работал, а потому не пробовал. Можно чуть подробнее или ссылку на конкретнуу статью, почему нельзя ON DELETE CASCADE на версионнике FOREIGN KEY на саму себя?

<Цитата>
sql (04.05.08 14:34) [10]

> trubin © (01.05.08 21:35)

Несовсем понятно СУБД какая ?

<Цитата>
kaif © (04.05.08 14:51) [11]

Скорее всего у тебя в дереве есть циклическая ссылка. То есть кто-то из потомков является предком одного из своих родителей. Или же предком самого себя. Скорее всего из-за этого и возникает у тебя бесконечная рекурсия.

<Цитата>