mitchspano/trigger-actions-framework

Discussion: Show Limits feature

Opened this issue · 6 comments

I'd like to develop a feature that could be activated per object, per handler, or (possibly) globally that would:
At the start of a handler, output some limits to the debug log
At the end of a handler, output some limits to the debug log

Of course, it's not a good idea to have this on in Production, as it would slow things down, but it could be a good tool for debugging in sandboxes.

Implementation:
A checkbox on each CMT record
(If global) A new CMT object with key-value pairs (for future scalable feature management) and a record called "ShowLimits" with a value "true."

This is code from an old handler repo I have that I could repurpose here:

if (showLimits) {
  System.debug(
    LoggingLevel.DEBUG,
    String.format(
      '{0} on {1} ({2}/{3} queries) and ({4}/{5} DML calls)',
      new List<String>{
      	this.triggerEvent + '',
      	getHandlerName(),
      	Limits.getQueries() + '',
      	Limits.getLimitQueries() + '',
      	Limits.getDmlStatements() + '',
      	Limits.getLimitDmlStatements() + ''
      }
    )
  ); 

Thoughts? Do people think this could be useful?

I think that this is an interesting idea that could dovetail nicely with other logging frameworks. That said, I don't think we'd want to introduce new dependencies.

What do you think about defining an interface (e.g. TriggerActionTelemetryLogger) that is registered via the existing CMDT?

While I'm not sure I understand how this is a dependency (since it would put in debug lines before and after each handler, written in the base class, I think that it would be interesting to create an interface. That feels pretty complicated for simple debug log lines, though.

Can you help me understand how there would be a new dependency? Maybe I'm not sure what dependency means here, since I'm not connecting to any other packages.

You've got me thinking about using plugin/interface to connect this to NebulaLogger in a smooth way. Thanks for that idea. Putting one piece in this package and maybe another piece in a NebulaLogger plugin might be useful. In fact, maybe this is what you were thinking: Could a connector package that would be dependent on both (without making each package dependent on any other packages) be useful?

I was thinking something akin to the way James Simone's Apex Rollup package handles this.

If we had a simple interface definition:

public interface ITriggerActionTelemetryLogger {
    public void log();
}

The implementation above may look something like:

public class LimitLogger implements ITriggerActionTelemetryLogger {

    public void log() {
        System.debug(
            LoggingLevel.DEBUG,
            String.format(
                  '{0} on {1} ({2}/{3} queries) and ({4}/{5} DML calls)',
                  new List<String>{
                  	this.triggerEvent + '',
                  	getHandlerName(),
                  	Limits.getQueries() + '',
                  	Limits.getLimitQueries() + '',
                  	Limits.getDmlStatements() + '',
                  	Limits.getLimitDmlStatements() + ''
                  }
            )
        ); 
    }

}

And it could be integrated into the framework like so:

if (telemetryEnabled) {
    ((ITriggerActionTelemetryLogger) Type.forName('ClassDefinedInCustomMetadata').newInstance()).log();
}

Yes! That's great. I think I'll start with a simple built-in logger, and then a Nebula Logger plugin. In small pieces so PRs are small. It looks like the advantage is that one can pick the best logging plugin for one's own org.

Just stopping by to say I'm super jazzed to see the discussions around Nebula Logger & Apex Rollup - if there's anything @jamessimone or I can do to help with some of this, let us know!

@jongpie Yesssss! I spent time yesterday looking at @jamessimone code and creating analogous CMTs in my fork. As this congeals, I'll keep everyone in the loop.

At a minimum, I think the capability to have plugins will be good, and hopefully others will ask for more insertion points in this framework. It feels like all the code hook insertion points on a Wordpress page - we just have to be smart about where to do things without slowing down the platform.