function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
ZGZG 

DescribeSObjectResult object returned by Schema.describeSObjects different than Schema.sObjectType.Account?

On https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_expressions_operators_understanding.htm
it is stated that:

"Unlike Java, == in Apex compares object value equality, not reference equality, except for user-defined types."
"For sObjects and sObject arrays, == performs a deep check of all sObject field values before returning its result. Likewise for collections and built-in Apex objects." 

Why are the two asserts below failing then? If you look at the debug logs with the "Debug Only" option selected you should see that all 3 objects re identical.

Are the asserts below failing for you as well or is it just a glitch in my dev org?

// Two different ways to get a DescribeSObjectResult object 
        DescribeSObjectResult dsor1 = Account.SObjectType.getDescribe();
        DescribeSObjectResult dsor2 = Schema.sObjectType.Account;
        
        // Another way to get the DescribeSObjectResult using the Schema object
        List<DescribeSObjectResult> l =  Schema.describeSObjects(new List<String> {'Account'});
        DescribeSObjectResult dsor3 = l[0];
        
        System.assert(dsor1 == dsor2); // succeeds
       //System.assert(dsor1 == dsor3); // fails
      // System.assert(dsor2 == dsor3); // fails
       System.assert(dsor1.getsObjectType() == dsor3.getsObjectType()); // succeeds
       System.assert(dsor2.getsObjectType() == dsor3.getsObjectType()); // succeeds
        
        // If you look at the debug logs with the "Debug Only" option selected
        // you should see that the objects below are identical
        system.debug('dsor1: ' + dsor1);
        system.debug('dsor2: ' + dsor2);
        system.debug('dsor3: ' + dsor3);

 
Best Answer chosen by ZG
Glyn Anderson 3Glyn Anderson 3
These are the attributes that differ:

["actionOverrides","childRelationships","fields","namedLayoutInfos","supportedScopes","urls"]

I'll leave it as an exercise to the reader to explore further...

All Answers

Glyn Anderson 3Glyn Anderson 3
I used JSON.serialize to compare the DescribeSObjectResults as strings.  I tried your 3 ways to get a DescribeSObjectResult plus one additional way.  Ways 1, 2, and 4 all return the same result, but way 3 returns a DescribeSObjectResult structure that is much larger and contains more information.  This might be handy to know.  Here's my code:

<pre>
DescribeSObjectResult dsor1 = Account.SObjectType.getDescribe();
DescribeSObjectResult dsor2 = Schema.sObjectType.Account;
DescribeSObjectResult dsor3 = Schema.describeSObjects(new List<String>{'Account'})[0];
DescribeSObjectResult dsor4 = Schema.getGlobalDescribe().get('Account').getDescribe();

String str1 = JSON.serialize(dsor1);
String str2 = JSON.serialize(dsor2);
String str3 = JSON.serialize(dsor3);
String str4 = JSON.serialize(dsor4);

System.assert( str1 == str2, '1/2: ' + str1 + '\n' + str2 );    // passes
//System.assert( str1 == str3, '1/3: ' + str1 + '\n' + str3 );  // fails
System.assert( str1 == str4, '1/4: ' + str1 + '\n' + str4 );    // passes
//System.assert( str2 == str3, '2/3: ' + str2 + '\n' + str3 );  // fails
System.assert( str2 == str4, '2/4: ' + str2 + '\n' + str4 );    // passes
//System.assert( str3 == str4, '3/4: ' + str3 + '\n' + str4 );  // fails
</pre>
Glyn Anderson 3Glyn Anderson 3
To be exact, ways 1, 2 and 4, return a structure that serializes into a string of length 11,889 characters.  Way 3 becomes a string of length 97,395.
Glyn Anderson 3Glyn Anderson 3
Some more investigation shows that at the top level, the two different DescribeSObjectResults have the same attributes:

dsor1:
["actionOverrides","activateable","childRelationships","compactLayoutable","createable","custom","customSetting","deletable","deprecatedAndHidden","feedEnabled","fields","hasSubtypes","isSubtype","keyPrefix","label","labelPlural","layoutable","listviewable","lookupLayoutable","mergeable","mruEnabled","name","namedLayoutInfos","networkScopeFieldName","queryable","recordTypeInfos","replicateable","retrieveable","searchLayoutable","searchable","supportedScopes","triggerable","undeletable","updateable","urls"]

dsor3:
["actionOverrides","activateable","childRelationships","compactLayoutable","createable","custom","customSetting","deletable","deprecatedAndHidden","feedEnabled","fields","hasSubtypes","isSubtype","keyPrefix","label","labelPlural","layoutable","listviewable","lookupLayoutable","mergeable","mruEnabled","name","namedLayoutInfos","networkScopeFieldName","queryable","recordTypeInfos","replicateable","retrieveable","searchLayoutable","searchable","supportedScopes","triggerable","undeletable","updateable","urls"]

So the additional size must come from something else.  There must be more information provided in one or more of these attributes.
Glyn Anderson 3Glyn Anderson 3
These are the attributes that differ:

["actionOverrides","childRelationships","fields","namedLayoutInfos","supportedScopes","urls"]

I'll leave it as an exercise to the reader to explore further...
This was selected as the best answer
ZGZG
Thank you Glyn, for the detailed research. Shouldn't all 4 of these objects be the same though, given that they are all DescribeSObjectResult objects for the Account object? Is this a bug on the Salesforce end?
Glyn Anderson 3Glyn Anderson 3
You might think they would be the same.  I wouldn't call this so much a bug as a quirk.  The fact that one method provides more describe information than another method reveals some internal workings of the Salesforce code.  It will be interesting sometime to explore the differences in more detail.  It might be useful to know what additional information one can get in Apex using the more verbose method.

Could you do me the favor of marking one of these posts as the "solution"?  Thank you!
ZGZG
I would appreciate it someone would report this issue to Salesforce. After clicking on "Contact Support" I am asked to login and after logging in and hitting "Contact Support" I am taken back to the login screen. It's a loop that won't let me enter the issue. Most likely because I am not a Salesforce customer or an employee of a company that is.
ZGZG
After comparing the two JSON strings at http://www.jsondiff.com/, here are the differences (the string on the left is str1, the one on the right is str3, the longer string):

​1. Both "actionOverrides" types should be nulls
2. Both "fields" types should be nulls
3. Both "namedLayoutInfos" types should be nulls
4. Both "supportedScopes" types should be nulls
5. Missing property uiDetailTemplate from the object on the left side
6. Missing property uiEditTemplate from the object on the left side
7. Missing property uiNewRecord from the object on the left side