Summer 14 Describe Patterns

On each release, developers eagerly look through the release notes for exciting new features. I’ve found that the things that excite me most often aren’t the same things that thrill others. I often get most excited about small changes – sometimes they can have a huge impact on software design patterns.

This summer, the biggest feature for me is the elimination of Describe limits. This eliminates a huge Catch-22 when developing on the platform. On one hand, good Apex code is supposed to respect field level and object security. But the previous Describe statement limit made it difficult and sometimes impossible to do so on larger applications and systems, where the number of fields processed in an execution context could easily exceed the available limits.

The elimination of Describe limits does, however, raise an interesting question. How does this change impact design patterns and could other limits come into play? Or put another way – how costly are Describe calls in terms of CPU time?

Prior to now, the best design pattern for using Describe statements involved caching each Describe call so that you could at least ensure that you don’t call getDescribe on a field more than once in an execution context. The design pattern looked something like the getDescribeInfo function below, where the parameters are the field name and SObjectField token for the desired field:

private static Map<String, Schema.DescribeFieldResult> fieldDescribeCache = new Map<String, Schema.DescribeFieldResult>();
private static Schema.DescribeFieldResult getDescribeInfo(String name, SObjectField token)
    if(!fieldDescribeCache.containsKey(name)) fieldDescribeCache.put(name, token.getDescribe());
    return fieldDescribeCache.get(name);

Does it still make sense to use this kind of pattern? Or should you just call getDescribe() whenever you need describe information?

To find out, I did some benchmarking using the techniques described in chapter 3 of the second edition of Advanced Apex Programming.

I found that the approximate cost of a Describe statement is about 3 microseconds. This looked pretty fast to me. Can the earlier design pattern, with its cost of an additional function call and map lookup, be any faster?

The answer, as it turns out, is no. The overhead of caching and looking up data exceeded any benefits that might have come from avoiding the extra Describe calls.

Further testing showed the same results with SObject describes as field describes.

I don’t know if Describe calls on summer 14 are fast because work went in to optimize them, or because the platform is now caching describe data internally for you, but it doesn’t really matter. It seems clear that going forward, the optimal design pattern for describe statements is to use them inline as needed.

New Course Teaches Data Visualization Using the Salesforce Platform

I’m pleased to announce my latest Pluralsight course “Data Visualization for Developers”. This is not a course on – but in some ways it’s even better. It teaches the principles and practice of data visualization using as an underlying technology.

The course is published on Free trials are available if you are not already a subscriber.

Find out more in this preview video:


Advanced Apex 2nd Edition Available!

I’m pleased to announce the immediate availability of the second edition of Advanced Apex Programming for and

A few months ago, when SFDC announced the elimination of script limits, I knew that it had finally happened – a change that really impacted some of the content of the book. That led to some major changes in chapter three. And I figured, as long as I’m working on the book anyway; why not add a few more changes?

Chapter 6 extends the discussion on triggers to clarify some points based on questions I’ve received over the past year.

Chapter 7 has significant new content on batch apex and scheduled apex asynchronous patterns

Chapter 8 is a new chapter on concurrency issues (the later chapters have been renumbered).

Plus, there are numerous other smaller changes and additions scattered throughout the book.

All told, the book has grown by about 50 pages.

It also has a snazzy new cover – making it easy to determine going forward which edition you’re looking at.

Also, unlike last year, I’m pleased to announce that the Kindle and Nook editions are also available for those of you who prefer the eBook format.

The book available now on several country sites, and I’ll be linking the others as they go live. The links on the left will take you to the new edition – it will take a few weeks before all of the channel databases are updated.

Dreamforce 2013 Sessions

I’ve been so busy for the past month that I haven’t had much time to post, but I’m pleased to say that I’ll be presenting three sessions at Dreamforce this year.

Monday at 11:15am, Moscone West -2009, High Reliability DML and Concurrency Design Patterns for Apex

It’s remarkable when you think about it, that even though is a highly scalable multi-user and multithreaded system, there is hardly any documentation on how to deal with Apex concurrency issues. I’m looking forward to shining some more light on this topic and sharing some of my own adventures (and misadventures).

Monday at 1:30pm, Hilton San Francisco Union Square – Community Success Zone Theater, Apex Design Patterns for Managed Packages

This one is for the ISV’s in the community, particularly the developers. Those of us who create managed packages are a growing minority – it’s nice to see us getting some more attention this year!

Tuesday at 5:15pm, Moscone West – 2024, Design Patterns for Asynchronous Apex

At first I was thinking – 5:15pm before the gala? Talk about bad timing. But then again, talking about timing (good and bad) is a large part of asynchronous apex, and if the late hour gives you a syncing feeling, so much the better 🙂

I hope to see many of you there. Also, be sure to attend the developer keynote on Wednesday 10:30 at Moscone South – Gateway.

And, I encourage you to visit this site sometime this weekend for another post that you may find of interest.


New course: for .NET Developers

I’m pleased to announce my latest Pluralsight course “ for .NET Developers”. This course is a prequel to my course “ and Apex Fundamentals for Developers” intended specifically for .NET developers who are curious about

Here’s how I describe the course: is a unique cloud development platform that is in many ways different from traditional software development platforms – even those based on cloud technologies. This short course is designed specifically for .NET developers to understand the nature of by comparing and translating .NET concepts to their equivalents.

If you are a .NET developer, I encourage you to check it out – if you’re not already a Pluralsight subscriber, they have a free trial available (see right sidebar for link).

Intriguing Design Pattern for Scheduled APEX

One of the disadvantages of Scheduled APEX is that a scheduled class can’t be updated. creates an instance of the APEX class when it is scheduled, preventing it from being updated. You can’t edit a scheduled class, or update it via a ChangeSet, the IDE or a package update.

What’s more, prevents updates to any dependent classes as well. Thus it is quite easy for a scheduled class to “poison” an application – preventing many, if not all of its components, from being updated. As a result, updates to applications that use Scheduled Apex often require any scheduled jobs to be manually aborted before an update can take place.

It turns out, however, that a recent API update allows use of a design pattern that can help you avoid most of these problems.

Here’s how it works.

You still create a class that implements the Schedulable interface, but this class will be a simple wrapper that defines it’s own interface – call it IScheduleTest. This interface is identical to Schedulable. The execute method of the Schedulable global class creates an instance of a second class that implements the new IScheduleTest interface using the new Type class instantiation method. It then calls the execute method on that interface. It looks like this:

global class ScheduleTest Implements Schedulable
  public Interface IScheduleTest
    void execute(SchedulableContext sc);

  global void execute(SchedulableContext sc)
    Type targettype = Type.forName('CalledByScheduleTest');
      IScheduleTest obj = 

The second class looks something like this:

public class CalledByScheduleTest 
  implements ScheduleTest.IScheduleTest
  public void Execute(SchedulableContext sc)
    System.debug('called in schedule');

What does this accomplish?

You still can’t modify the ScheduleTest class once it’s scheduled, but this class is so simple, you may never need to update it. You can update the CalledByScheduleTest class. Using the Type.NewInstance method to create the class dynamically prevents the platform from seeing it as a dependent class.

I’ve been able to successfully update the CalledByScheduleTest class even during a managed package update as long as the scheduled ScheduleTest class remains unchanged. Though this design pattern is not officially documented (to my knowledge), I see no reason why it should not work reliably going forwards.

This design pattern eliminates one of the major impediments to using Scheduled Apex and is worth not only considering for new designs, but as a possible retrofit to existing applications.