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
sfdcfoxsfdcfox 

[Seeking Admin Input] VF Bug "SObject Row was retrieved without requesting..." managed package

In a Developer Edition with a managed package that the org manages, we know that salesforce.com is smart enough to know that all code without a namespace is running in the org's default namespace, which is the namespace of the managed package. This means that we can write the following code in Visualforce with impunity:

 

<apex:inputField value="{!CustomObject__c.SomeField__c}"/>

Salesforce.com knows there's no ambiguity and is able to successfully resolve the reference without any help or hint on the developer's part. Looking at the same code in an organization where this code is installed yields the following insight:

 

<apex:inputField value="{!namespace__CustomObject__c.namespace__SomeField__c}"/>

The uploader knows that it has to prepend the namespace into these value attributes so that the fields can be resolved at compile time in the target organization, and everything works as expected. However, when you're not using an attribute value, such as a "normal" formula-style merge field, we run into a problem:

 

{!CustomObject__c.CustomField__c}

When you try to load this page into the target organization, everything installs fine, but when you try to run the page, you get the following exception:

 

SObject row was retrieved without requesting the following field: CustomField__c

When you look at the source code, you'll see that the merge field was unaffected by the uploader, and consequently, the code won't run at all. Worse, since the package is managed, the only solution is to modify your code to make sure the generated SOQL contains namespaces, which means you have to write these fields thusly:

 

{!namespace__CustomObject__c.namespace__CustomField__c}

This is problematic from several standpoints, but perhaps the most trying question here is: why are attribute values correctly fixed, while merge fields are not? Is this documented somewhere as to why this happens? Is it a bug, or a feature?

 

From my perspective, this could be a bug, since it means you have to hardcode in namespace values, so you can't use the code in a portable fashion: You can neither upload it as a non-managed package to another org without fixing the code, nor can you sync this code across developer orgs without some additional work.

 

However, if it is indeed a feature, I'd like to know where this is documented, and why merge formulas don't work while attribute values do work. I'm making this public so that this can be documented for future developers that may also have this question. I couldn't seem to find a post that specifically mentioned this bug or feature (however it might be labelled).

 

This question was posed to Dev Support, and they came back with "you need to use the namespaces", which doesn't tell anyone about the "why" it works this way, if it was designed this way, will it happen this way in the future, or anything else even remotely useful. I had already worked out that we would need namespaces in these merge fields, or we would have to wrap them in apex:outputPanel tags, or even use wrapper classes, but I wanted to know if this is on anyone's roadmap, or if there's a legitimate, albeit undocumented, purpose behind this limitation.

aballardaballard

sounds like a bug to me.