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
Paul Dyson.ax812Paul Dyson.ax812 

Querying local fields from within a Managed Package

We have a bit of an odd situation with a package installed in a client org. We have a managed package - let's say the prefix is MPackage__ - and a custom field on Contact Custom_Field__c. The client also has a field on Contact called Custom_Field__c. If we want to query these from the system log the difference is obvious:


'select MPackage__Custom_Field__c from Contact' - for our packaged field




'select Custom_Field__c from Contact' - for the 'local' field


How would we distinguish them from inside the package? If we use 'select Custom_Field__c from Contact' inside the package its automatically prefixed with the namespace MPackage__ and so refers to our packaged field, not the local field. Obviously, most of the time, this is exactly correct, but in this case we want to be able to distinguish between the two fields and treat them differently. We know there are two fields because the SObject method returns them differently in response to getName() but we can't work out how to query the local one.


Any ideas?



Bhawani SharmaBhawani Sharma

You cann't  query the local field from the installed package. B'coz when a package is installed it first run the schema  and create all the object and fields included in the package.

Bhawani SharmaBhawani Sharma

However yopu want to query the local field. You can describe the Schema object and can get the field local Api name using getLocalName() method and can create a dynamic SOQL query .


is this make sense ?

Paul Dyson.ax812Paul Dyson.ax812

We are using dynamic SOQL but the problem remains - getLocalName returns Custom_Field__c in both cases and querying on Custom_Field__c from inside a managed package seems to assume MPackage__Custom_Field__c if it exists and Custom_Field__c if it doesn't. In our case it does but that's not the one we want to query.

Bhawani SharmaBhawani Sharma

you can do one more thing.

You can cerate a custom setting and keep the field api name in it.  You can use the Custom setting value to create the query, So if if you want to query the local field, just define My_Custom_Field__c or if you want to query the packaged field then you can put the MPackaged__My_Custom_Field__c  in custom setting.

Paul Dyson.ax812Paul Dyson.ax812

I don't think I'm making myself sufficiently clear. The problem is not identifying which field we want to query (we have that stored in the database). The problem is actually querying it. If you execute:


Database.query('select Custom_Field__c from Contact');


within a managed package Salesforce assumes you want to query MPackaged__Custom_Field__c if it exists - it automatically adds the namespace if a field of that name exists within the managed package. What we're looking for is a way of telling Salesforce that we actually want to query the non-namespaced 'local' Custom_Field__c, not MPackaged__Custom_Field__c.


Hi Paul,


If the code below is running in a subscriber org, then it should be picking up the subscriber field.  Only case might be if there is a field in your package and the sub org with the same field name.  Is that the case?



Paul Dyson.ax812Paul Dyson.ax812

Hi Andrew,


yes, that's exactly the problem we have; we have a field in our package that has the same name as a field in the subscriber org. We want to query the subscriber's field but can't work out how to do so. Is there any way to do this?






Hi Paul,


I'm afraid there isn't a solution to this short of renaming the field in the subscriber org to something different than what the name is in your package.  We currently don't have a notation that says "use the subscriber field, not the packaged field".  The problem is that:


select id, fieldA__c, fieldB__c from objectA__c




select id, myNS__fieldA__c, myNS__fieldB__c from myNS__objectA__c


both return the fields in your package.  It's when a match isn't found that the system then looks for a local field in the subscriber org with that name.