대량 삭제 전 트리거 (너무 많은 Soql 문) Salesforce.com

Question

지도를 사용하여 SOQL 거버너 제한으로 실행되지 않도록하는 방아쇠가 있습니다. 이 트리거는 재귀 및 쿼리 제한을 위해 정적 클래스 변수도 사용합니다.

삽입 또는 업데이트와 같은 대량 작업이 개체,이 경우 연락처 개체에서 시작되면 트리거가 관련 트리거 계정의 맵을 첫 번째 트리거에 작성하여 사용할 것입니다. 나머지 트리거 발사를위한지도. 여기

는 있지만 삽입 트리거 작업 후 업데이트 & 후를 위해 큰 노력하고 있습니다 작업의 예는 다음과 같습니다 정적 클래스 변수가 사실이 아니다

1. 확인하는 것이.

2. 변수가 true가 아닌 경우 빌드 맵.

3. 정적 클래스 변수를 true로 설정하십시오.

4. 트리거 작업을 수행하십시오.

삽입/업데이트 트리거의 경우 세션 상태가 유지되고 대량 작업이 끝날 때까지 정적 클래스 변수가 재설정되지 않습니다.

그러나 이전 삭제 트리거의 경우 세션 상태가없는 것으로 보이며 레코드가 삭제 될 때마다 세션이 재설정됩니다. 세션은 다시 설정되지만 조정자 한계는 레코드의 대량 삭제에 대해 누적됩니다. 따라서 삭제 전 트리거를 사용하더라도 맵을 사용하더라도 soql 쿼리 카운트는 100 개가 넘는 레코드를 삭제할 수있는 악명 높은 '너무 많은 SQL 쿼리'제한을 계속 계산합니다.

SOQL 한도로 실행되는 것을 방지하는 방법에 대한 생각은 많이 감사하겠습니다. 나는이 곳 어디에서도 아무것도 찾을 수 없었다.

Answer 1

취할 수있는 옵션은 트리거를 사용하여 batch apex class for execution을 예약하는 것입니다. 어떤 객체가 계단식 삭제를 시작할지 모르는 경우 트리거를 사용하여 배치의 인스턴스를 만들고 소스 ID의 목록을 전달합니다.

그런 다음 배치 클래스의 execute 메소드에서 각 배치에 대해 맵 등을 빌드하고 거기에서 삭제를 수행 할 수 있습니다. 일괄 처리 정점은 동기 실행을 희생하면서 총재 한계를 상당히 상회하며 프로세스가 일반적으로 2 ~ 3 초 내에 시작한다고 말했습니다.

이 외에도 계단식 삭제가 항상 최대한 큰 목록 (최대 200 개까지)에서 항상 작동하도록 코드를 최적화하는 경우 일 수도 있고 마스터 세부 관계를 사용하여주의를 기울일 수도 있습니다 일부 삭제 작업에 대한 정보가 있습니까?