Массовая обработка перед триггером удаления (слишком много операторов Soql) Salesforce.com

Question

У меня есть объемный триггер, который использует карты, чтобы избежать ограничения SOQL-регуляторов. Этот триггер также использует статические переменные класса для рекурсии и для ограничения запросов.

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

Вот пример операции, которая отлично работает, но только для триггерных операций после обновления и после вставки:

1. Убедитесь, что статическая переменная класса не соответствует действительности.

2. Если переменная не верна, построить карты.

3. Установите для статической переменной класса значение true.

4. Выполните триггерные операции.

Для триггеров вставки / обновления состояние сеанса сохраняется, а переменная статического класса не сбрасывается до окончания массовой операции.

Однако для триггера перед удалением кажется, что состояние сеанса отсутствует и сеанс сбрасывается при каждом удалении записи. Сеанс сбрасывается, но ограничения регулятора накапливаются для массового удаления записей. Таким образом, при использовании триггера перед удалением, даже при использовании карт, количество запросов soql продолжает подсчитывать, достигая печально известного предела "Too Many Sql Queries" для удаления более 100 записей.

Любые мысли о том, как предотвратить ограничение SOQL, будут высоко оценены. Я нигде не смог найти ничего по этому поводу.

Answer 1

Один из вариантов, который вы можете использовать, - использовать триггер, чтобы запланировать выполнение класса вершины пакета. Для которого когда-либо является объектом, который запускает каскадное удаление, используйте триггер для создания экземпляра пакета, передавая ему список идентификаторов источника.

Затем в методе execute класса пакета вы можете затем построить карты и т. Д. Для каждого пакета и выполнить удаление в нем. Пакетная вершина имеет значительно более высокие пределы регуляторов за счет синхронного выполнения, что говорит о том, что процесс обычно запускается в течение пары секунд после вашей операции.

Кроме этого, это может быть просто случай оптимизации вашего кода, так что каскадное удаление всегда работает с списками как можно большего размера (конечно, до предела 200), или, возможно, вы могли бы использовать отношения Master Detail, чтобы позаботиться о некоторых из удалить операции для вас?