Inspection error reported when returning soql query directly in a method
Given the following code snippets, Line #2 shows inspection error "Cannot Resolve Symbol". It only happens to the Project__c object and my assumption is that it is because there is a managed package that shares the same name minus the namespace. If I return the query to a variable rather than as a return statement the code is not flagged.
return [SELECT Id FROM Account];
return [SELECT Id FROM Project__c];
return [SELECT Id FROM TaskRay__Project__c];
List<Project__c> results = [SELECT Id FROM Project__c];
This has no affect on saving or running the code it just shows up as an error in the inspection results.
Comments (16)
-
repo owner -
repo owner Just to clarify, what is the return type of the containing method? Is it
List<Project__c>
,List<TaskRay__Project__c>
,List<SObject>
, or a single item version of one of those? -
reporter Containing method is
List<Project__c>
. I also found that this reports the same error as well:public Database.QueryLocator start(Database.BatchableContext context) { return Database.getQueryLocator([SELECT Id FROM Project__c]); }
-
repo owner Thanks, John. You say that it only happens with
Project__c
, and only when used without the namespace qualification. Is that right? That matches what I see in the provided screenshot where bothProject__c
and itsId
are highlighted in red meaning they're unresolvable. My guess is that your project is misconfigured slightly with regard to the namespace. When you look at the connection properties for the project's connection, what does it show for Organization namespace? If it doesn't showTaskRay
, click the Test button and that should not only verify the credentials, but also fetch the namespace from the org. If that does populate the org namespace properly for the connection, regenerate your OST and I think these issues should go away. If none of that is as as-speculated, or if that doesn't help resolve the issue, let me know. -
reporter I should have clarified.
Project__c
exists twice in the system. Once has a custom object under the default namespace and secondly asTaskRay__Project__c
.This is a client org that has a custom object called
Project__c
but also has the TaskRay managed package installed which has it's ownProject__c
object. Other than the inspection tools flagging it everything compiles and runs fine. -
repo owner Ah, okay. And yes, these inspections errors are raised 100% by IC's own parser and type inference engine. When there are false negatives, it's a bug I need to address. And that's always fun given how...quirky...Apex is as a language. I'll keep trying to reproduce it given the info you've provided. I'll let you know if I have any problems. Thanks for all the details!
-
repo owner - changed component to Code Inspections and Intentions
-
repo owner John, before I dig into this, quite a large number of fixes have occurred in this area. Would you mind seeing if the problem is still reproducible? Thanks!
-
reporter Hi Scott, I made sure I was on the latest version of everything and opened up the project that had this scenario and it does appear to still be an issue.
Again, it's not preventing me from doing anything it just shows up as a conflict it can't resolve in the editor.
-
repo owner Thanks for checking, John. That's all I needed to know. I don't mind jumping in and reproducing/fixing it, but it sounded very similar to a few things I'd already fixed so I figured it was worth checking before digging in. Thanks again!
-
repo owner John, I've obviously let this languish for much too long and wondered if you could confirm what I'm actually debugging with me. The simple attempts to reproduce this aren't forcing the error. Reviewing the comments, it looks like we suspected that the underlying problem was IC incorrectly resolving to the wrong
Project__c
object when you had a local one and one from a managed package (that should require namespace qualification to be resolved properly). Is that correct?Or perhaps another question would be whether this problem still occurs for you. I have implemented a large number of fixes in this area since early March. If it does, please help refresh my memory on the exact nature of it so that I can take care of it finally. Thanks!
-
repo owner Never mind...I was able to reproduce it by modeling a local custom object with the same name as a custom object from an installed managed package. Shame on me for not doing that before now!
-
repo owner Fix submitted for inclusion in the next build.
-
reporter Hi Scott, Sorry I wasn't able to respond sooner I was out of town this past weekend. But looks like you were able to reproduce the issue. Let me know if you need me to do any testing on my end.
-
repo owner Oh, no problem. I'll be posting the new build shortly (in the next hour most likely). Once you update just let me know if the issue still exists for you.
-
repo owner - changed status to resolved
Delivered in 2.0.3.0 and 1.8.3.6.
- Log in to comment
Thanks for reporting, John. I'll let you know if I can't reproduce it, but assuming I can, I'll plan to address it for the next build.