Перенос организационной структуры между приложениями

Здравствуйте!

Попробуйте отключить триггер TRSysAdminUnitRoot (пакет Base) и затем попробовать переместить данные.

Только перед этим протестируйте или сделаейте копию БД/приложения.

"Мотков Илья" написал:

Здравствуйте!

Попробуйте отключить триггер TRSysAdminUnitRoot (пакет Base) и затем попробовать переместить данные.

Только перед этим протестируйте или сделаейте копию БД/приложения.

Спасибо, после отключения триггера, обновление данных завершилось успешно.

Спасибо за решение.



А подскажите, пожалуйста, как включение и выключение триггера добавить в пакет, чтобы не выполнять эти скрипты каждый раз вручную?



Отключать триггер, наверное можно "Before saving package", а вот когда включать?



И второй вопрос - почему импорт SysAdminUnit выполняется так долго (50 минут, хотя в данных всего около 20 ролей и 10 пользователей)? Может быть, можно ещё что-то отключить и выполнить единоразово после всего импорта?

 

2020-10-29 17:19:06,697 [5] INFO NT AUTHORITY\SYSTEM InstallZipPackage LogInfo - Lookup values "States_Provinces" from package "Exactly.Data" installed
2020-10-29 18:05:40,163 [5] INFO NT AUTHORITY\SYSTEM InstallZipPackage LogInfo - Lookup values "SysAdminUnit" from package "Exactly.Data" installed

Ну, наверно, если отключать на «Before», то включать на «After». Такой вариант тоже есть:

А что может так сильно тормозить этот импорт?

Всё, что угодно, например, ещё какие-то триггеры, которые не отключили (и, возможно, отключать и не стоит). Попробуйте посмотреть в SQL-профайлере на отрабатывающие запросы.

Тщательно протестировали. Триггер не отключается перед установкой почему-то на Before...

Ясно. Выходит, сначала идёт AfterPackage и уже затем AfterSchemaData.

Но при этом иногда стала появляться такая ошибка из того же триггера:

 @Terrasoft.Core,SysAdminUnitSchema.Exception.RootAlreadyExists



То есть, кажется, он успевает включиться до того, как данные начинают импортироваться (пробовали и After package saved, и After Schema data saved.

Если убрать включение триггера, то всё проходит без ошибок. Но кто тогда будет включать триггер?

Судя по RootAlreadyExists, ругается на какую-то конкретную запись, которую считает корневой. Всё ли правильно в залитом? А если в скрипте перед включением триггера задержку вставить?

Да, сначала даже подумал, что в пакете какие-то записи с пустым ParentRoleId. Но посмотрел - нет таких.

Возможно, что при импорте данных что-то дёргает уже существующие All employees, и потому срабатывает триггер.



Сейчас видим, что, в принципе, триггер относительно бесполезный (если администратор не начнёт ничего рушить), потому можно его вообще отключить.

Насчёт задержки была мысль, но тут второй непонятный вопрос - иногда эти данные SysAdminUnit импортируются 5 минут, иногда час, иногда два... И это при том, что их штук 20 всего.



Но после импорта SysAdminUnit и SysUserInRole хорошо бы запустить процедуру tsp_ActualizeAdminUnitInRole. Но пока тоже не совсем понятно, куда её воткнуть...

	IF (TG_OP = 'INSERT' OR TG_OP = 'UPDATE') AND TG_WHEN = 'AFTER' THEN
		IF (NEW."ParentRoleId" IS NULL AND NEW."SysAdminUnitTypeValue" < 4) THEN 
 
			IF (NEW."SysAdminUnitTypeValue" > 0) THEN
				RAISE '@Terrasoft.Core,SysAdminUnitSchema.Exception.InvalidRootType';
				ROLLBACK;
			END IF;
 
			SELECT COUNT("Id") INTO RecordsCount FROM "SysAdminUnit"
				WHERE "ParentRoleId" IS NULL
					AND "SysAdminUnitTypeValue" < 4
					AND "SysAdminUnit"."Id" <> NEW."Id";
 
			IF (RecordsCount > 1) THEN
				RAISE '@Terrasoft.Core,SysAdminUnitSchema.Exception.RootAlreadyExists';
				ROLLBACK;
			END IF;
 
		END IF;
	END IF;

Если импорт выполняется долго по непонятной причине, попробуйте смотреть в профайлере, что за запросы долго работают.

Если есть тестовый стенд, где без каких-либо доработок, просто при добавлении данных такая долгая заливка воспроизводится, можете написать в поддержку для её анализа.

Вероятно, ту функцию актуализации, которую хотите запустить, нужно тоже на одном из «After...».

Идея по невозможности заливки в SysAdminUnit уже заведена, как обходное решение рекомендуется в пакете скриптами включать-выключать триггер.

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