Record Types

The Force.com 201 blog posted a great example of how to query the record type table in salesforce in a way that's considerate toward governor limits - think memoization pattern.

It's a useful technique and I've used it on every major project I've worked on over the last few years. However, there is another way to get record type information. Take the following example:

List oppRecTypes = Opportunity.SObjectType.getDescribe().getRecordTypeInfos();

There are also the following methods:

Map oppRecTypesByID = Opportunity.SObjectType.getDescribe().getRecordTypeInfosByID();

Map oppRecTypesByName = Opportunity.SObjectType.getDescribe().getRecordTypeInfosByName();

These all return RecordTypeInfo objects in some way, shape or form, but without using up one of you SOQL queries! These calls are not without penalty however - instead of a SOQL query, you use up a "record type describe", which you have a hundred of in a transaction on EE. So you'll still want to apply the memoization (cache) pattern explained in the Force.com 201 blog.

There is one other drawback - RecordTypeInfos do not appear to have any reference to the developer name of a record type. Really, both record type names and developer names can be changed pretty easily which could introduce breakage to your code, however developer names are less likely to change in my opinion, so querying the record type table can be a safer option.

Too many script statements?

With any luck, this weekend should be the go-live for the project I mentioned in my last post. It's been an interesting project, and, at the risk of sounding schmaltzy, there have been a lot of lessons learnt (and most of them painfully).

I'll be posting about some of the lessons learned in upcoming posts, but I just wanted to take a moment to an idea I have up on Ideas. The governor limit on script statements has been my main obstacle this time around; I know that it's part of multi-tenancy and working with Salesforce. I don't actually mind operating within those limits, but I do like being able to handle meeting those limits in a sensible way.

The reason that "Too many script statements" is special is that, when hitting other governor limits, you can catch them as exceptions and handle them appropriately - usually displaying an error to the user. However, once you've used too many script statements, you don't have any script statements left to tidy up or present something meaningful to the user.

There are ways around this - not hitting the limit in the first place (not a practical solution this time round), periodically checking how many statements have been used and throwing an exception at a threshold (fiddly, unpredictable and uses script statements!). But a neater solution would be nice.

Feel my pain? Don't mope, promote!