How can I identify a deprecated managed package custom field via the APIs?

Question

I'm in the process of doing some development in a random¹ client org where they want an integration with another parties managed package.

Part of this is to run SOQL queries against custom objects and fields from the managed package.

As part of my testing I was running the following query successfully in the Developer Console Query Editor.

Select Id, SBQQ__Primary__c, SBQQ__Opportunity__c from SBQQ__Quote__c

Yet when I tried to use the same SOQL query from a new Apex class it wouldn't save with the message:

No such column 'SBQQ__Opportunity__c' on entity 'SBQQ__Quote__c'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.

Odd, as I can clearly see this field in the describeSObject Metadata for SBQQ__Quote__c (which is how I built up the SOQL query).

      <fields>
           <aggregatable>true</aggregatable>
           <autoNumber>false</autoNumber>
           <byteLength>18</byteLength>
           <calculated>false</calculated>
           <cascadeDelete>true</cascadeDelete>
           <caseSensitive>false</caseSensitive>
           <createable>true</createable>
           <custom>true</custom>
           <defaultedOnCreate>false</defaultedOnCreate>
           <deprecatedAndHidden>false</deprecatedAndHidden>
           <digits>0</digits>
           <filterable>true</filterable>
           <groupable>true</groupable>
           <idLookup>false</idLookup>
           <inlineHelpText>Opportunity being quoted.</inlineHelpText>
           <label>Opportunity</label>
           <length>18</length>
           <name>SBQQ__Opportunity__c</name>
           <nameField>false</nameField>
           <namePointing>false</namePointing>
           <nillable>false</nillable>
           <permissionable>false</permissionable>
           <precision>0</precision>
           <queryByDistance>false</queryByDistance>
           <referenceTo>Opportunity</referenceTo>
           <relationshipName>SBQQ__Opportunity__r</relationshipName>
           <relationshipOrder>0</relationshipOrder>
           <restrictedPicklist>false</restrictedPicklist>
           <scale>0</scale>
           <soapType>tns:ID</soapType>
           <sortable>true</sortable>
           <type>reference</type>
           <unique>false</unique>
           <updateable>false</updateable>
        </fields>

Note that deprecatedAndHidden is false.

The field section from the sObject Metadata is similar:

  <fields>
    <fullName>SBQQ__Opportunity__c</fullName>
    <deprecated>false</deprecated>
    <description>Opportunity being quoted.</description>
    <externalId>false</externalId>
    <inlineHelpText>Opportunity being quoted.</inlineHelpText>
    <label>Opportunity</label>
    <referenceTo>Opportunity</referenceTo>
    <relationshipLabel>Quotes</relationshipLabel>
    <relationshipName>Quotes</relationshipName>
    <relationshipOrder>0</relationshipOrder>
    <reparentableMasterDetail>false</reparentableMasterDetail>
    <trackHistory>false</trackHistory>
    <trackTrending>false</trackTrending>
    <type>MasterDetail</type>
    <writeRequiresMasterRead>false</writeRequiresMasterRead>
  </fields>

---

The Custom Object pages make it clearer that the field is no longer part of the active package.

From the Quote Custom Field detail page it is very clearly deprecated².

How can I tell via the APIs (preferably describeSObject) that a field is deprecated in the managed package that defined it?

Update: I think I need something like the Package Version Header used by the REST API so I can indicate the specific version of the namespace I'm interested in. There is an equivalent header for the Partner WSDL - Package Versions and the Partner WSDL

---

¹ Random as in not my regular orgs, I didn't just log into any org I could to start writing Apex)

² I'm aware I could alter the Version Settings on the class/trigger in question to the older version of the managed package to access the field. However, that isn't my objective.

Answer 1

I don't think there is flag or field in metadata that give us this particulate information.

Considering above fact we will need to need to depend on workarounds.

One of such workaround is using the Package version number. We can query the installed package version number using following query.

SELECT DurableId, Id, IsSalesforce,MajorVersion,MinorVersion, Name,NamespacePrefix FROM Publisher where Name =:p_name limit 1

Once we get the MajorVersion/MinorVersionnumber its just matter of adding if condition around your SOQL for ex:

Publisher p = [SELECT DurableId, Id, IsSalesforce,MajorVersion,MinorVersion, Name,NamespacePrefix FROM Publisher where Name =:p_name limit 1];  

if(p.MajorVersion > X && p.MinorVersion >Y){  
    //SOQL with SBQQ__Opportunity__c 
}else
{
    //SOQL with SBQQ__Opportunity2__c 
}

If you want make it more sophisticated you can use custom setting decide for which version which SOQL should be used.

Edit 1: We can even go further with dynamic apex and make it easy to maintain. Note that i am not saying "its maintenance free" but its easy to maintain

We can store query in custom setting for each version. Here is sudo code that should do the magic :

Publisher p = [SELECT DurableId, Id, IsSalesforce,MajorVersion,MinorVersion, Name,NamespacePrefix FROM Publisher where Name =:p_name limit 1];  
String ver_number = p.MajorVersion + '.'+  p.MinorVersion

String queryString = '';

List<VerionSoql__C> vsl  = VerionSoql__C.getall().values();

for(VerionSoql__C vs : vsl)
    if(vs.ver__c == ver_number) {
        String queryString = vs.query__c; // Dynamically get the query for the current version 
        break;
    }
}
list<SBQQ__Quote__c> lst = Database.query(queryString);

for(SBQQ__Quote__c o : lst)
    System.debug('>>>' + childRecord.get('SBQQ__Opportunity__c'); // Dynamically get the field value
    System.debug('>>>' + childRecord.get('SBQQ__Opportunity2__c'); // Dynamically get the field value
}

Note 2 important things

1. We will need to maintain the custom list of SOQL queries for each version. We can automate this using InstallHandler but again this class will need to be updated for each deprecation.
   2. above code is just sudo code and so there can be few syntax error but i am 100 sure that logic will work.