5

This is really a strange bug.

Inside my managed package I have a NAMESPACE_CustomObject__c with a NAMESPACE_CustomField__c.

In one of my packaged classes I have an Aggregate Query

String soql = 'SELECT MAX(Amount__c), CustomField__c ' + 
              'FROM CustomObject__c ' +
              'GROUP BY CustomField__c';

for(AggregateResult result : Database.query(soql)) {    
   doSomething( result.get('CustomField__c') ); 
}

When this code executes it fails with...

Invalid field CustomField__c for AggregateResult

if and only if the customer also added a non-packaged field with the sames name CustomField__c to NAMESPACE_CustomObject__c .

Is this a bug or am I doing something wrong. If not this is a perfect way to screw every managed package. Don't you agree?!

If forgot to mention that our dynamic SOQL query is intended to query the customers field and NOT ours. I just simplified the code for this example. Our code is configurable and will query fields the customer can create and define. So we do NOT have any problems when our internal fields are queried like this but only when the customer configures our software in a way that it tries to query a non-packaged field that exits also in our package.

1
  • 1
    I recommend adding an extra prefix to managed fields. So the package would use someprefix_CustomObject__c, which when packaged would be NAMESPACE__someprefix_CustomObject__c. This makes it easier to identify/sort/group fields when debugging and reduces the chances of accidentally adding the wrong field to a package. It also reduces the chance of a naming conflict. That may be why I've never seen this bug. And yes, I do think it's a bug.
    – kibitzer
    Jun 24, 2013 at 18:47

1 Answer 1

5

One of our developers Chris Peterson has a case raised with Salesforce 09290363, in it he is currently discussing with the support team if it is a bug or not. Our feeling is it is a bug and agree with you though it maybe an edge case in some respects, it also could be quite tricky to get out from, especially if the duplicate name was introduced as part of an upgrade and the unmanaged field has been in place for some time. The only workaround we have been given is to rename the field, which depending on the circumstance may not be possible and/or desirable. Of course we can follow up on this answer if/when we get some news on the status of this issue. In the meantime at least we can be aware of its potential.

7
  • Is this already aknowledged by Salesforce as a "Known Issue" on their size? Jun 24, 2013 at 13:30
  • 1
    Its currently being categorised as a feature request, will keep you posted. Jun 24, 2013 at 14:02
  • 1
    Is the SOQL using the full NAMESPACE_CustomField__c in the SOQL string? I saw something similar when using sObject and Get for field values - but when I added the full namespace to the field, it worked... Jun 24, 2013 at 16:02
  • 1
    @Robert I'm happy either way re: keeping the question open, I've made a note internally to update this when/if we get any news different from above. :-) Jun 25, 2013 at 12:28
  • 1
    As the Chris Peterson in question, it's been escalated and is awaiting PM response to determine if it's classified as a bug or feature request. In summary, SOQL always adds your package's namespace if it can, which makes un-namespaced fields shadowing yours impossible to query. You can get describes for and assign values to them, but never read them. Jun 26, 2013 at 0:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .