Форум: "Базы";
Текущий архив: 2008.11.23;
Скачать: [xml.tar.bz2];
ВнизДерево в БД - проблема при удалении узла Найти похожие ветки
← →
trubin © (2008-05-01 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 © (2008-05-01 22:33) [1]> "Too many concurrent executions of the same request"
Это где-то у тебя на триггере или ХП сервер рекурсивно в бесконечный цикл уходит. По умолчанию - не более 1000 уровней рекурсии положено.
Или данные в таблице корявые, или еще где-то триггер есть, который ты не привел.
← →
trubin © (2008-05-01 23:48) [2]
> Или данные в таблице корявые, или еще где-то триггер есть,
> который ты не привел.
Триггер на delete один во всей базе
← →
DrPass © (2008-05-02 02:12) [3]Поставь его на before delete
← →
MsGuns © (2008-05-02 02:43) [4]Групповое удаление на само по себе опасная штука, а если оно еще зашито в триггер, то неприятности обеспечены
← →
trubin © (2008-05-02 10:55) [5]
> Поставь его на before delete
Сразу пробовал - та же картина
> MsGuns © (02.05.08 02:43) [4]
> Групповое удаление на само по себе опасная штука, а если
> оно еще зашито в триггер, то неприятности обеспечены
Это я понимаю, вот только сколько не гуглил, книжки не листал особо не помогает...
Буду думать :)
← →
trubin © (2008-05-03 18:55) [6]
> PEAKTOP © (01.05.08 22:33) [1]
Ты прав, проблема была в данных. Но удаление потомков из триггера все-таки убрал - засунул в рекурсивную ХП.
← →
Prohodil Mimo © (2008-05-03 20:39) [7]а ON DELETE CASCADE не помогает или это хуже триггера?
← →
PEAKTOP © (2008-05-03 23:14) [8]> а ON DELETE CASCADE не помогает или это хуже триггера?
На версионнике ? Еще раз повторяю: не на блокировочнике, а на версионнике FOREIGN KEY на саму себя ?
> проблема была в данных
Деревья просто снятся но ночам :) в кошмарах ...
← →
Prohodil Mimo © (2008-05-04 14:28) [9]PEAKTOP © (03.05.08 23:14) [8]
а почему нет? всё же происходит в одной транзакции.
С деревьями в FB не работал, а потому не пробовал. Можно чуть подробнее или ссылку на конкретнуу статью, почему нельзя ON DELETE CASCADE на версионнике FOREIGN KEY на саму себя?
← →
sql (2008-05-04 14:34) [10]
> trubin © (01.05.08 21:35)
Несовсем понятно СУБД какая ?
← →
kaif © (2008-05-04 14:51) [11]Скорее всего у тебя в дереве есть циклическая ссылка. То есть кто-то из потомков является предком одного из своих родителей. Или же предком самого себя. Скорее всего из-за этого и возникает у тебя бесконечная рекурсия.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2008.11.23;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.007 c