soql Select using QualifiedApiName throwing error

[data...@gmail.com]

Hello,

I have a custom metadata class which stores objects and fields.  It stores them as Id numbers, but I also need the QualifiedApiName.  When I run the query in the SOQL Query window I get the results I am expecting, but when I put the query into my code, it is being highlight as an error.  The error is "Cannot resolve symbol 'QualifiedApiName'".  Here is an example screenshot:

Is there a way that I can acknowledge the error so that it no longer shows up in the list of errors in the class?

Thanks in advance!

Donna

[Scott]

Donna, the issue starts with the relationships through which QualifiedApiName is being referenced as they're also unresolvable (and therefore highlighted in red). I don't know how recent these relationship fields are, but if they're more recent than the last time you generated your offline symbol table (OST), that would explain it. Please regenerate your OST allowing the project to close and reopen and let me know if that doesn't resolve the issue for you.

Regards,

Scott Wells

[Chris S]

Scott,

I am encountering the same issue, which persists after an OST regen:

In this case, the __c fields are fine and picked up by IC2, but the __r relationships/attribute are not.

Chris

[Scott]

Hi, Chris. Yes, I'm investigating this now. I've gotten some logs from Donna via email and have requested additional logs. My guess is that it's something specific to relationship fields in custom metadata types. I'll also try to reproduce it locally. If it's what I suspect, it seems like it should be pretty easy to reproduce and fix. I'll keep you both posted.

Regards,

Scott

[Scott]

Hmmmm...I just tried to reproduce this in a naive fashion by creating two custom metadata types with a relationship between them, then I generated the OST. I see both sides of the relationship properly rendered into the OST:

/**
 * <h3>Parent MDT</h3>
 */
global class Parent_MDT__mdt extends SObject 
{
    global List<Child_MDT__mdt> Child_MDTs__r;
    global String DeveloperName;
    global static final SObjectTypeFields fields;
    global String Label;
    global String Language;
    global String MasterLabel;
    global String NamespacePrefix;
    global String QualifiedApiName;
    global SObjectType SObjectType;

    global Parent_MDT__mdt()
    {
    }
}

and:

/**
 * <h3>Child MDT</h3>
 */
global class Child_MDT__mdt extends SObject 
{
    global String DeveloperName;
    global static final SObjectTypeFields fields;
    global String Label;
    global String Language;
    global String MasterLabel;
    global String NamespacePrefix;
    /**
     * <h3>Parent MDT</h3>
     * <h3>Field Attributes</h3>
     * <table border="0" valign="top">
     * <tr><td><b>Data Type:</b></td><td>Metadata Relationship</td></tr>
     * <tr><td><b>Required:</b></td><td>true</td></tr>
     * <tr><td><b>Unique:</b></td><td>false</td></tr>
     * <tr><td><b>External ID:</b></td><td>false</td></tr>
     * </table>
     */
    global Id Parent_MDT__c;
    /**
     * <h3>Parent MDT</h3>
     * <h3>Field Attributes</h3>
     * <table border="0" valign="top">
     * <tr><td><b>Data Type:</b></td><td>Metadata Relationship</td></tr>
     * <tr><td><b>Required:</b></td><td>true</td></tr>
     * <tr><td><b>Unique:</b></td><td>false</td></tr>
     * <tr><td><b>External ID:</b></td><td>false</td></tr>
     * </table>
     */
    global Parent_MDT__mdt Parent_MDT__r;
    global String QualifiedApiName;
    global SObjectType SObjectType;

    global Child_MDT__mdt()
    {
    }
}

I tried this both with and without the corresponding *_mdt files in the local project, and both ways the OST looks correct to me.

Is there something else about these relationship fields that aren't getting properly rendered into the OST, or are they just standard MDT-to-MDT relationship fields? Assuming that they are stock-standard MDT relationship fields, I'll likely need to get detailed debug logs from OST generation from one or both of you to continue trying to diagnose this.

Regards,

Scott

[data...@gmail.com]

In my case, the Metadata type has fields which link to custom objects and fields within that object.  Not two metadata objects with a parent child relationship.

[Scott]

Aha...let me play with that a bit. Hopefully that leads to a reproduction of the issue. Thanks for clarifying!

Regards,

Scott

[Chris S]

Scott,

Ditto to the above poster, these are all entity/field definition links.

Chris

[Scott]

Yep, that did it. Hopefully shouldn't be hard to debug and fix. I've logged an issue in the public tracker here:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/1414/custom-metadata-type-entity-field

Feel free to watch that for progress on resolution. I'm currently working on a new build for very early next week. If time allows I'll get the fix for this into that build. Otherwise it would be in the build after that.

Thanks for reporting and helping to corner it!

Regards,

Scott

[Phil W-S]

We also see this issue and have lived with it for a couple of years now :D

Something that Donna and Chris may be interested in from the perspective of having Custom Metadata Types that have schema Object ("EntityDefinition" references with type "MetadataRelationship") and Field ("FieldDefinition" references with type "MetadataRelationship" and a metadataRelationshipControllingField that refers back to the Object MDT field) - loading the custom metadata instances is quick, but getting the QualifiedApiName values is REALLY slow (takes 10s of milliseconds for each access, at least the first time that specific schema object's schema details are requested in a given session). This is because it uses Dynamic Schema access. Take a look at https://salesforce.stackexchange.com/questions/262146/how-to-improve-schema-access-performance/262147#262147 for some discussion on these two schema access modes.

[Phil W-S]

Sorry, I wasn't finished but can't edit the previous comment...

While the CMT instance editing is far easier and you don't have to hard-code picklists of object types and fields, be aware that if you load a lot of CMT instances and need to resolve the object type and field API names you could easily end up using a significant amount of CPU time - we had it such that it was taking almost a second of CPU time just to load this detail on EVERY request in certain circumstances (while the CMT SOQL query was actually only costing maybe 50ms). It can have a significant impact on performance and can even push you over into CPU limits being exceeded if you have a lot of your own processing to do as well...

[data...@gmail.com]

Thanks Phil,  

I think I'm going to change and stop using the Entity Definition and Metadata Relationship fields.  I wasn't aware of the impacts of getting the QualifiedApiNames.  I'll just enter the QualifiedApiNames into text fields instead.

:)

Donna

[Scott]

Okay, I've fixed this for the next build. Here's the result of an OST generation for a custom MDT with entity and field definition relationships:

Custom MDT

/**
 * <h3>Parent MDT</h3>
 */
global class Parent_MDT__mdt extends SObject 
{

    ...
    /**
     * <h3>Entity Definition Link</h3>

     * <h3>Field Attributes</h3>
     * <table border="0" valign="top">
     * <tr><td><b>Data Type:</b></td><td>Metadata Relationship</td></tr>

     * <tr><td><b>Required:</b></td><td>false</td></tr>

     * <tr><td><b>Unique:</b></td><td>false</td></tr>
     * <tr><td><b>External ID:</b></td><td>false</td></tr>
     * </table>
     */

    global Id Entity_Definition_Link__c;
    /**
     * <h3>Entity Definition Link</h3>

     * <h3>Field Attributes</h3>
     * <table border="0" valign="top">
     * <tr><td><b>Data Type:</b></td><td>Metadata Relationship</td></tr>

     * <tr><td><b>Required:</b></td><td>false</td></tr>

     * <tr><td><b>Unique:</b></td><td>false</td></tr>
     * <tr><td><b>External ID:</b></td><td>false</td></tr>
     * </table>
     */

    global EntityDefinition Entity_Definition_Link__r;
    /**
     * <h3>Field Definition Link</h3>

     * <h3>Field Attributes</h3>
     * <table border="0" valign="top">
     * <tr><td><b>Data Type:</b></td><td>Metadata Relationship</td></tr>

     * <tr><td><b>Required:</b></td><td>false</td></tr>

     * <tr><td><b>Unique:</b></td><td>false</td></tr>
     * <tr><td><b>External ID:</b></td><td>false</td></tr>
     * </table>
     */

    global Id Field_Definition_Link__c;
    /**
     * <h3>Field Definition Link</h3>

     * <h3>Field Attributes</h3>
     * <table border="0" valign="top">
     * <tr><td><b>Data Type:</b></td><td>Metadata Relationship</td></tr>

     * <tr><td><b>Required:</b></td><td>false</td></tr>

     * <tr><td><b>Unique:</b></td><td>false</td></tr>
     * <tr><td><b>External ID:</b></td><td>false</td></tr>
     * </table>
     */

    global FieldDefinition Field_Definition_Link__r;
    ...

    global Parent_MDT__mdt()
    {
    }
}

EntityDefinition

global class EntityDefinition extends SObject 
{
    ...

    /**
     * The reciprocal relationship for <a href="psi_element://Parent_MDT__mdt.Entity_Definition_Link__c"><code>Parent_MDT__mdt.Entity_Definition_Link__c</code></a>.
     */
    global List<Parent_MDT__mdt> Parent_MDTs__r;
    ...

    global EntityDefinition()
    {
    }
}

FieldDefinition

global class FieldDefinition extends SObject 
{
    ...
    /**
     * The reciprocal relationship for <a href="psi_element://Parent_MDT__mdt.Field_Definition_Link__c"><code>Parent_MDT__mdt.Field_Definition_Link__c</code></a>.
     */
    global List<Parent_MDT__mdt> Parent_MDTs__r;
    ...

    global FieldDefinition()
    {
    }
}

Hopefully that will put this to rest. Thanks again for the input!

Regards,

Scott Wells