Hacking a Salesforce.com Autonumber Field for Importing
July 23rd, 2009
Joe Krutulis here at Appirio revealed this little gem to me today and I thought it an extremely creative work around for Salesforce.com.
The use case is that you have a custom object that contains an autonumber field. Towards the end of your project, the customer informs you that they want to load legacy data and set the autonumber with their historical value from their external system. The solution would typically be to change the field from an autonumber to a text field, load the records into Salesforce.com and then change the field back to an autonumber.
The problem is that if your Apex code references this field, Force.com is not going to allow you to change the field type. The solution is to fool the compiler by using the sObject get/put methods instead referencing the field explicitedly in your Apex code. This way Force.com will allow you to change the type of the field to a text field, import your data with the correct sequence and then change the field back to an autonumber.
Current code
1 2 | myObj.name = 'My Object Name'; |
New “Compiler-fooling” code
1 2 | SObject myObj = new MyObject(); myObj.put('name','My Object Name'); |
Categories: Apex, Salesforce
I certainly understand and appreciate the desire to minimize code management for seemingly benign administrative changes to field metadata but this approach should be used sparingly, if at all.
One of the great benefits of the strong typing of Apex is system integrity enforcement. By dropping to use of dynamic Apex you lose this tremendous benefit.
In your sample above you are putting a value into the sobject – presumably for later insert or update. If the field is an autonumber this code will actually fail at runtime because autonumbers are not editable – something the compiler tells you long before the code is ever deployed in the case of a static reference.
Given the current restrictions around the standard name field on custom objects this approach is seemingly benign when the reference in code is read-only, i.e. there is no attempt to insert/update/upsert the value but this is a special case.
If the pattern continues and is applied to custom fields then there is no stopping anyone with appropriate permissions from unknowingly renaming or deleting the field and thus breaking the code that depends on it.
Dynamic Apex is meant for use by code that is unaware of what it needs at compile time.
I agree with the prior comment. Sure you got around the compiler, but once you save the object it will error on you (I tried with an update triggers). The name field is not editable.