0

My org has a manage package installed. Is there any way to detect how many SOQL calls it has done in apex? I have code that fires because of it. Once a certain number of SOQL calls have been attempted by the manage package, I'd like my code to do something else.

4
  • Why do you care where the SOQL is coming from? Just check Limits.getQueries().
    – Adrian Larson
    Commented Aug 22, 2019 at 4:04
  • doesn't that query only apply to my namespace?
    – Tyler Zika
    Commented Aug 22, 2019 at 4:06
  • No, it checks against all the governors that count against the current transaction. It wouldn't include certified managed package code, but if it is a query run from any package that counts against you, it will show.
    – Adrian Larson
    Commented Aug 22, 2019 at 4:07
  • Darn, I want to check the certified manage package's SOQL usage. That is what is throwing the error.
    – Tyler Zika
    Commented Aug 22, 2019 at 4:08

2 Answers 2

1

Limits Class will always run in the same namespace it is being run from. So, the limits it returns will be of the same namespace limits and does not include any other namespace limits.

However, you can go to Salesforce developer console > Debug > Change log levels > Add/Change for General trace and set all levels to none but profiling to INFO or more. This will give detailed info on how the managed package limits have increased at each level in whole transaction. Debug log will look something like below (Notice the Pandadoc namespace limits). Using this info, it can be atleast be starting point for implementing something.

enter image description here

1

Unless the managed package exposed a method that let you examine this data, there's no way you would be able to tell in Apex. You might ask the vendor if they would add such a method. For example, they might add a Debug class, like this:

global class Debug {
  global static Integer getLimitsQueries() {
    return Limits.getQueries();
  }
}

They could do the same for other statements as well. This could give you insight via Apex. Aside from this technique, there's no way to know without reading debug logs, which would not be readable inside the same Apex transaction.

1
  • I wanted to propose this but I was somewhat skeptical whether this will even work - because - 1. this has to be separate class/method to get the limits. 2. Within 1 dml (by calling getLimits before and after dml), the difference in limits may shoot up (like, from 10 soqls to 50 soqls). 3. Because of that, @TylerZika cannot really do something when soqls hit 30. Am I thinking correctly? Commented Aug 22, 2019 at 13:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .