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

Question

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

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

Вот пример операции, которая работает отлично, но только для After Update иОперации триггера после вставки:

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

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

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

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

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

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

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

Answer 1

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

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

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