7

While I was working on a Visualforce page which has some similar functionality to another page that has already been developed in the past into one of my other orgs, I decided to re-use the same code to save some time.

After I did all the refactoring and went to test the page I got:

Attempt to de-reference a null object in my piece of code that was performing a Describe method for a field, which has previously been retrieved by the Schema.GetGlobalDescribe() method.

I found that odd because the very same functionality works without a problem into the old org. Then I thought it might be Field Level Security for that particular field. Went to check that, the FLS was set to false for all profiles, which made me go in the old org and try the same. After I disabled FLS in the old org, the page was still working without the problem, I was able to get the field name and perform a Describe on it.

Last thing that would be different was the API version of the Class. The old org was running v26.0 and the new one v34.0. That made me run some experiments which resulted in the following:

TL;DR;

  • The access to the sObject fields in Schema.GetGlobalDescribe() has been changed in v34.0.

Below is the code and the result respectively, running in v33.0 and below and v34.0 and above:

Schema.GetGlobalDescribe().Get(SObjectName).GetDescribe().Fields.GetMap().get('Field__c').getDescribe().getName()

v33.0 and below

output: Field__c

v34.0 and above

output: System.NullPointerException: Attempt to de-reference a null object

So I went to check the release notes for Summer '15 (v34.0) and I could not find any reference to the changes made to these Classes/Methods.

I'm wondering whether this is a bug, or expected behaviour and was missed in the documentation. Potentially this could break existing code if the API version of the Apex is changed.

6

So, I was wrong about the Class/Method changes. I am not going to remove this question because I hope it will help someone else.

It turns out if you're in a packaging org (like me) and have namespace enabled, the API v34.0 requires the namespace prefix for the describe calls. It's interesting the fact that adding the namespace prefix to the field worked in all versions (from 26 all the way to the current version), but trying to describe the field without the namespace prefix only worked until v33.0.

Schema.GetGlobalDescribe().Get(SObjectName).GetDescribe().Fields.GetMap().get('prefix__Field__c').getDescribe().getName() - works in all versions

Schema.GetGlobalDescribe().Get(SObjectName).GetDescribe().Fields.GetMap().get('Field__c').getDescribe().getName() (without the prefix) - works only up to v33.0

Again, I went through the release notes for v34.0 and could not find anything at all pointing to this change.

I'd very much appreciate if you could point me to the right place where this is documented.

  • 2
    There is some documentation about the differences based on the current namespace - DescribeSObjectResult missing fields when executed in managed package. However, that doesn't correspond to a change in v34.0. – Daniel Ballinger May 2 '16 at 19:22
  • Thanks @DanielBallinger, I was looking at the wrong place initially. It's weird how they changed the behaviour and it's not documented. This can have a catastrophic impact on existing managed packages if the API version of the class changes. – Boris Bachovski May 3 '16 at 2:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.