0

SOQL ガバナ制限に達するのを避けるために、マップを使用する一括トリガがあります。このトリガーは、再帰およびクエリの制限のために静的クラス変数も使用します。

私が行っているのは、挿入や更新などの一括操作がオブジェクト (この場合は連絡先オブジェクト) で開始されると、トリガーは最初のトリガーで関連する取引先のマップを作成し、それらのマップを残りのトリガー発射。

以下は、うまく機能している操作の例ですが、After Update および After Insert トリガー操作に対してのみです。

  1. 静的クラス変数が true でないことを確認してください。

  2. variable が true でない場合、マップを作成します。

  3. 静的クラス変数を true に設定します。

  4. トリガー操作を実行します。

挿入/更新トリガーの場合、セッション状態は維持され、静的クラス変数は一括操作が終了するまでリセットされません。

ただし、before delete トリガーの場合、セッション状態はないようで、レコードが削除されるたびにセッションがリセットされます。セッションはリセットされますが、ガバナー制限はレコードの一括削除に対して累積的です。そのため、削除前のトリガーを使用すると、マップを使用している場合でも、soql クエリ数がカウントされ続け、100 を超えるレコードを削除するための悪名高い「Too Many Sql クエリ」の制限に達します。

SOQL の制限に達するのを防ぐ方法についてのご意見をお待ちしております。私はこれについてどこにも何も見つけることができませんでした。

4

1 に答える 1

1

実行できるオプションの 1 つは、トリガーを使用してバッチ Apex クラスの実行をスケジュールすることです。カスケード削除を開始するオブジェクトに対して、トリガーを使用してバッチのインスタンスを作成し、それにソース ID のリストを渡します。

次に、バッチ クラスの execute メソッドで、各バッチのマップなどを作成し、そこで削除を実行できます。Batch apex では、同期実行を犠牲にしてかなり高いガバナ制限があり、プロセスは通常、操作から数秒以内に開始されます。

これ以外に、カスケード削除が常に可能な限り大きなリスト (もちろん最大 200 の制限) で機能するようにコードを最適化する場合や、マスター ディテール リレーションシップを使用していくつかの処理を行うことができます。操作を削除しますか?

于 2011-11-04T00:16:04.017 に答える