function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
EJWEJW 

Winter '13 bug comparing a generic sobject field containing certain 18 character strings.

It appears there's a new bug in Winter '13 where Salesforce.com is automatically trying to convert text fields on sobjects to IDs if the string is 18 characters when using the sObject.get() method.  For example, this code will throw an exception about an invalid ID:

 

SObject contact1 = new Contact( FirstName = 'Test', LastName = 'Tester', Phone = '000000000000000000' );

System.debug( contact1.get( 'phone' ) == '000000000000000000' );

 

Exception thrown: System.UnexpectedException: Invalid parameter value "000000000000000000" for parameter "id".

 

I've opened a case for this already but I'm posting it here as well as the board sometimes gets a quicker response.  The case number is 08285129.  This bug is causing exceptions with some our large customers preventing them from modifying their data in some cases.

 

Thanks,

sfdcfoxsfdcfox

Interesting. Must be a new feature. I'd recommend that you always cast to the intended data type when comparing against an Object type, such as ( String.valueOf( contact1.get('phone')) == '000000000000000000' ).

 

Edit: Forgot a paren.
EJWEJW
sfdcfox wrote:

Interesting. Must be a new feature. I'd recommend that you always cast to the intended data type when comparing against an Object type, such as ( String.valueOf( contact1.get('phone')) == '000000000000000000' ).

 

Edit: Forgot a paren.

This is not a feature, it is a bug.  The version I posted here was a simplified version of this, which fails with the same error:

 

---------------

SObject contact1 = new Contact( FirstName = 'Test', LastName = 'Tester', Phone = '000000000000000000' );
SObject contact2 = new Contact( FirstName = 'Test2', LastName = 'Tester2', Phone = '000000000000000000' );
System.debug( contact1.get( 'phone' ) == contact2.get( 'phone' ) );

----------------

 

That type of comparison has been working since generic sObjects were released and is how we determine which fields have changed during an update trigger.  This type of comparison broke with Winter '13 but only for 18 character strings and only certain strings, not all.  My theory is that strings that do evaluate to a potentially valid ID do not throw the exception, while strings that don't evaluate to an ID cause the exception.

 

Thanks,
sfdcfoxsfdcfox

Well, it is a bug, certainly, but the intent behind it is a feature. It represents a way whereby ID values can be tested against strings without an explicit conversion. For example, this previously failed:

 

map< id, account > accounts = ...

accounts.get('00130000003FkaZ');

But now happily works in the updated release. I agree that they probably should have left well enough alone; a string is a string, and never an ID, unless its cast or constructed using Id.valueOf(), or, if they were to leave it this way, enforce the concept of promotions, such as in Java.