Custom Metadata entity field's QualifiedApiName is reported as error by code inspector

[Aidan Harding]

When using Custom Metadata in Apex with a field of type "Metadata Relationship(Entity Definition)", the inspector incorrectly reports a reference to the QualifiedApiName as an error.

e.g. if I have a My_Metadata__mdt with a field called

My_Entity__c

, then I should be able to write

List<My_Metadata__mdt> myMetadata = [SELECT My_Entity__r.QualifiedApiName FROM My_Metadata__mdt];

The inspector says that

My_Entity__r.QualifiedApiName

is an unresolved reference.

[Scott Wells]

Aidan, let me model a custom metadata relationship and see if I can reproduce this. If so it should be trivial to fix. I'll let you know if I have any trouble.

[Scott Wells]

Aidan, I've been unable to reproduce this. I've modeled two metadata types with one having a relationship to the other, regenerated the OST so that both are fully represented in it, and the following code produces no errors and all symbols can be navigated to the corresponding declarations:

List<Other_Setting__mdt> otherSettings = [SELECT Expense_Setting__r.QualifiedApiName FROM Other_Setting__mdt];

Had you regenerated the OST at the time that this problem occurred? If not, does that resolve it for you? If so and the problem is still happening, can you let me know if there's anything I've done differently from you so that I can try again to reproduce it?

[Aidan Harding]

Hi Scott,

I don't know why this isn't working the same for you as for me. I've found some odd OST problems since IC2, and it seems to work better in DX projects over other projects. One other factor is that many of my projects are from old IC, and I just rebuilt them when I upgraded to IC2. Maybe something in that?

I've just tried adding a new Custom Metadata Type to an old dev org of mine (originally IC1). It has one entity-reference field,

An_Entity__c

and one field-reference field,

A_Field__c

The OST file follows, and (as-expected) trying to query something like

[SELECT Id, An_Entity__r.QualifiedApiName FROM IC_Test__mdt]

Gives an error in the code inspector.

// Generated by Illuminated Cloud on Mon Feb 19 10:39:57 GMT 2018. Do not edit.

/**
 * <h3>IC Test</h3>
 */
global class IC_Test__mdt extends SObject 
{
    /**
     * <h3>An Entity</h3>
     */
    global String An_Entity__c;
    /**
     * <h3>A Field</h3>
     */
    global String A_Field__c;
    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 IC_Test__mdt()
    {
    }
}

[Scott Wells]

Hmmmm...when you regenerate your OST for IC2, are you doing a partial regen or a full regen? If you do a full regen it shouldn't matter if it was upgraded from IC1 ("shouldn't" being the operative word since, if it does, that would be a bug). There also shouldn't be a difference between SFDX and MDAPI projects in this regard. The main differences there are how it picks up connections and how it deploys/retrieves metadata. Everything around the OST, reference injection, and code inspections should be identical.

If you haven't already, can you do a 100% full regen on the OST and allow the project to close/reopen to see if that resolves the issue. If it doesn't we may need to schedule a screenshare so we can compare what we're doing to see if we can nail down the difference.

[Aidan Harding]

Hi Scott,

I was using the "Generate Offline Symbol Table" button in the toolbar, choosing to do a Full one, then reloading the project instead of restarting the IDE afterwards.

Since your comment, I've tried again and restarted the IDE but no joy. Happy to book in a screen-share if that would help. Hopefully, I'm not doing something dumb!

I've also had Custom Labels showing up as undefined references in IC2. I thought regenerating the OST would fix it, but it didn't. In some of my projects it works, in others it doesn't, so I hadn't filed a bug because I give you anything to reproduce it with. The custom metadata doesn't work in any of my projects.

[Scott Wells]

Custom labels are currently resolved against local *.labels files and not against the OST. If you're seeing red there then pull down the custom labels metadata into the project. I have thought about including those in the OST as well, but on most projects I've seen folks have them locally already. I'd be interested in any thoughts you have on that.

As for the original problem, yeah, I think a screenshare may be the best next step. What are some times that you're available? I generally try not to let IC interfere with my "day job" for separation of concerns purposes (aside from responding to email/issue tracker/discussion group support messages), so on weekdays I'm available in the mornings before work, during lunch, and of course after work. I'm in Central Standard Time (GMT-6). Throw out some times that might work for you and I'll send a Hangouts invite so that we can get to the bottom of this issue. Thanks!

[Aidan Harding]

Hi Scott,

How about 2pm GMT on 22 Feb? Or any time on 23 Feb up to a 4.30pm GMT finish.

PS I mentioned this discussion to one of my developers and he tried pulling down the custom label on a project that was originally IC1. It was still a reference error. He tried on a fresh IC2 project and it worked for him. Hopefully, it will turn out to be all one issue, otherwise I'll raise a new issue. See where we get with custom metadata first, I suppose.

[Scott Wells]

Hi, Aidan. I sincerely apologize but I somehow missed your last comment. I promise that I haven't been purposefully ignoring you! I should be able to do a screenshare sometime this week to take a look if that also works for you. Please let me know some times that you might be available and I'll set something up. Again, sincere apologies for the long-delayed response!

[Aidan Harding]

Hey Scott, no problem. I'm really busy at the moment, but will try to arrange a time with you in the next few weeks.

[Scott Wells]

I'm fairly certain that this was addressed quite a bit back. Please let me know if not.