EvgIq,
не огрызайтесь, деточка
если вы сбежали от санитаров, это не повод пытаться править миром
кодинг, это не гениальные идеи, а банальные рефлексы по их реализации
и, в т.ч. реализации даже далеко не жениальных идей
судя же по вашему коду -- вы нуб в бд вообще и в postgresql -- в частности
поэтому мсскл вам ничем не хуже.
некоторые ваши собеседники кстати имеют опыт реализации "вот этого всего", что вы с придыханием, с большенььких, да на латинской буквице. резюме опыта -- бред это всё собачий. если на это всё равно тянет -- жениться срочно. ну или к санитарам взад. на процедурки
Но к делу:
егоров правильно вам написал по мелочи:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CREATE OR REPLACE FUNCTION const_ch()
RETURNS integer AS
$BODY$ -- устанавливаем допустимое количество Детей у элемента в дереве
SELECT 3;
$BODY$
LANGUAGE sql IMMUTABLE
COST 10;
CREATE OR REPLACE FUNCTION const_lv()
RETURNS integer AS
$BODY$
-- устанавливаем допустимое количество Уровней в дереве
SELECT 4;
$BODY$
LANGUAGE sql IMMUTABLE
COST 10;
-- это конечно всё "не существенно", для изобретателей велосипедов, но когда база из за таких кодеров встаёт колом -- приходится доставать полено -- и заниматься промежушной педагогикой
Далее тот же егоров парвильно вам написал про вставку первого.
А то, что вы вместо правки своего жениального овнокода вдарились в рассуждения про джанго выявило в вас (не впервый раз) прожектёра.
правится это примерно так (не думая):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
CREATE OR REPLACE FUNCTION new_id_board()
RETURNS trigger AS
$BODY$DECLARE
lv integer; -- количество уровней в дереве
ch integer; -- допустимое количество детей
id_new bigint; -- вычесляемый id нового элемента
id_p bigint; -- id родителя
lv_p integer; -- уровень родителя
count_childs_p integer; -- количество детей родителя
BEGIN
-- для создания нового элемента достаточно заполнить у него поле parent
id_p := NEW.parent_id;
ch := const_ch();
lv := const_lv();
-- найдем родителя
SELECT lvl, count_childs INTO lv_p, count_childs_p FROM board_group WHERE board_group.id=id_p;
IF NOT FOUND THEN
lv_p:=0; count_childs_p:=0;
NEW.lvl := 0;
ELSE
-- Проверка 1: может ли родитель еше иметь детей
IF count_childs_p >= ch THEN
RAISE EXCEPTION 'Родителю c id=% более нельзя иметь детей (их количество уже %)', id_p, ch;
END IF;
-- Проверка 2: может ли родитель иметь детей
IF lv_p = lv THEN
RAISE EXCEPTION 'Элементу с id=% нельзя иметь детей (его уровень % максимально возможный)', id_p, lv;
END IF;
NEW.id := ((power((ch+1),(lv-lv_p-1)))*(count_childs_p+1))::bigint+id_p;
NEW.lvl := lv_p + 1;
END IF;
NEW.count_childs := 0;
NEW.nm := NEW.id; -- ЭТО ТОЛЬКО ДЛЯ ТЕСТОВ, затем убрать
RAISE NOTICE ' %', NEW;
UPDATE board_group SET count_childs = count_childs_p+1 WHERE board_group.id = id_p;
return NEW;
END;$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION new_id_board()
OWNER TO postgres;
- это не ревизия а просто заплатки на лету, не вдумываясь. пока такие мелочи в рефлексы не забьёте -- к здоровым людям с вопросами не приставайте. не поймутс.
бесконечно лень вчитываться в вашу пену слов и кода, т.ч. предположу, что вас,
возможно , спас бы перенос AFTER DELETE логики в заключение в BEFORE DELETE [могу врать, но есть подозрение, что это так]
т.е.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
-- заглушка ----------
CREATE OR REPLACE FUNCTION del_id_board_after()
RETURNS trigger AS
$BODY$DECLARE
old_p_id bigint;
old_p_lv integer;
old_p_ch integer;
i integer;
BEGIN
/*
-- возьмем Родителя удаленного Элемента
SELECT id, lvl, count_childs
INTO old_p_id, old_p_lv, old_p_ch
FROM board_group
WHERE id=OLD.parent_id;
IF (old_p_ch > 0) THEN
--- RAISE EXCEPTION 'old_p_id=%, old_p_lv=%, old_p_ch=%, OLD.id=%',old_p_id, old_p_lv, old_p_ch, OLD.id;
i := fill_emp(old_p_id, old_p_lv, old_p_ch+1, OLD.id);
END IF;
*/
RETURN NULL;
END;$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION del_id_board_after()
OWNER TO postgres;
--------------------------------------------------------
CREATE OR REPLACE FUNCTION del_id_board_before()
RETURNS trigger AS
$BODY$DECLARE
old_p_id bigint;
old_p_lv integer;
old_p_ch integer;
i integer;
BEGIN
IF OLD.count_childs > 0 THEN
RAISE EXCEPTION 'У данного элемента имеются дети в количестве % шт. Удалите сначала их.', OLD.count_childs;
END IF;
-- возьмем Родителя удаленного Элемента
SELECT id, lvl, count_childs
INTO old_p_id, old_p_lv, old_p_ch
FROM board_group
WHERE id=OLD.parent_id;
-- уменьшим количество детей у родителя
UPDATE board_group SET count_childs = count_childs-1 WHERE id = OLD.parent_id;
----------------- -----------------
IF (old_p_ch > 0) THEN
--- RAISE EXCEPTION 'old_p_id=%, old_p_lv=%, old_p_ch=%, OLD.id=%',old_p_id, old_p_lv, old_p_ch, OLD.id;
i := fill_emp(old_p_id, old_p_lv, old_p_ch+1, OLD.id);
END IF;
----------------- -----------------
RETURN OLD;
END;$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION del_id_board_before()
OWNER TO postgres;
-- если я вру -- поправьте, желательно на пальцах.
(там реально думать надо [о видимостях и т.п.], а это затратно, а повода нет)
теперь -- почему нет повода:
id дерева -- это, как правило, ссылка на сущность, на которую ссылаются другие объекты (а не только оно само -- уробороссом) . каскадный апдейт всей базы, это то, за что не увольняют, а закапывают на месте. даже в блокировочнике. в случае версионника -- это еще и дублирование занятого дискового, и последующая глобальная сборка мусора [в postgresql -- воркерами автовакуума]
повторяю, в этом случае вам не помогать нужно, а вязать вас санитарами, пхать в смирительную, и на процедурки
так что, чтобы повысить юзабельность вашего макетика (который у вас рассыпается) сделайте отдельно -- board_id суррогат, неизменый. -- На него будете ссылаться снаружи, без всех этих каскадов. Вместо id и parent_id я бы ввел key и parent_key -- для читаемости, но это вопрос предпочтений и наличного кода.
