#Salesforce duplicate detector apex update
#Salesforce duplicate detector apex code

Looking at the Nebula Bitbucket shows that a lot has changed since the article was written last year many updates to the framework, and a lot of potential. That seems hard for the next guy to learn, to be honest Since it’s something I’ve spent quite a bit of time thinking about as I pondered the LazyIterator framework, I directed them to read the Nebula Consulting post on Lazy Iterators. Somebody recently asked a question regarding the performance and organization of Apex triggers as they grow, and possible design patterns for cleaning up complicated handlers. I think anybody who’s converted a lead at the start of a greenfield project versus several years into the implementation can attest to the fact (which I have cited previously in the React.js versus Lightning Web Components post) that delays as small as 50ms can both be detected and negatively impact the end user experience. With smaller number of records, of course, such increases are hardly noticeable - until they are. That’s a 4.47% increase in processing time. Starting execute after gathering sample records, time passed: 0.403 seconds

#Salesforce duplicate detector apex update

We’ll just update the AccountHandler object so that the beforeInsert method contains some vanilla processing methods as I had shown earlier: This should give you a good idea, per 10k records, how long it takes at baseline to process records. I tested various other org structures, including those with Duplicate Rules enabled, workflows, validation rules, etc … while those definitely slow down the resulting insert (Standard duplicate rules for Accounts added nearly 7 seconds to the processing time), the vast majority of the time was simply in creating that many objects. Something that should be immediately obvious in looking at these results? It’s not the setting up of the savepoint or the Account list that is leading to any kind of slowdown this is just how long it takes for Salesforce triggers to process large record sets in 200 increment batches. It’s important to note that the baseline is being measured prior to the Savepoint being rolled back. Starting execute after gathering sample records, time passed: 0.788 seconds

#Salesforce duplicate detector apex code

This code is going to interact with our extremely plain AccountHandler object, called by the trigger on Accounts: Public class AccountHandler extends TriggerHandler It’s also not uncommon for people to underestimate the performance implications that come with using these functions - in JavaScript’s vanilla functions’ case, our code’s readability increases at the cost of performance: Eager Evaluation in JavaScript & Apex While fluency as a property of functions/objects has become associated more with functional programming than with OOP, many developers are being unwittingly exposed to pseudo-fluent interfaces (and, as a result, functional paradigms) through the JavaScript collection API it’s not uncommon to see various filter, map, and reduce calls being chained together when iterating through lists in JavaScript. What can Salesforce developers writing Apex code stand to gain by learning more about lazy functions?įluent interfaces - or objects that return themselves during function calls - also tend to satisfy one of the prerequisites for Object-Oriented Programming namely, encapsulation. It’s common for lazy functions to be chained together using fluent interfaces, culminating with actions being performed when the terminator function is called. So-called “Lazy” evaluated functions have their actual execution delayed until a “terminator” function is called. A Short History Of Lazy EvaluationĪll problems in computer science can be solved using one more level of indirection. Additionally, if the quote on indirection interests you below, you might also enjoy reading my article on organizing invocable and static code. This article is assuredly better for his input. I’d also like to thank Aidan for generously proof-reading the beta version of this, which led to a couple of great edits. Their LazyIterator object uses the Decorator pattern to add functionality to the underlying iterators found on all Salesforce List objects 2 - reading through their codebase got me re-excited about working with collections in Apex. The idea for this article has been brewing since then. 1 I was impressed at the time with the object-oriented approach that Aidan Harding and the folks over at Nebula Consulting had undertaken when implementing the Lazy Iterator framework.

Welcome back to the Joys Of Apex! You may remember from the footnotes of Sorting & Performance In Apex that I mentioned an article on lazy iteration, which I first read in February while browsing the Salesforce subreddit.