SOQL parser mishandles aliases

Issue #715 resolved
Phil W created an issue

If I have something like:

List<AggregateResult> shifts = [SELECT Team__c team FROM Shift__c WHERE Team__c IN :team_ids AND (Scheduled_Start_Time__c >: dt OR Actual_Start_Time__c >: dt) GROUP BY Team__c];

for(AggregateResult a : shifts){
   Id team_active = (Id)a.get('team');
   team_ids.remove(team_active);
}

Where I am introducing the 'team' alias for use with a.get() a couple of lines later, I get an error flagged in the editor saying "',', '.' or <soql alias> expected, got 'team'". This seems incorrect to me.

Running in IDEA 2017.2.4.

Comments (15)

  1. Eric Alexander

    Phil,

    Your question is a bit unclear as

    [SELECT Team__c team FROM Shift__c]
    

    Is not valid SOQL syntax and would product the error

    "only aggregate expressions use field aliasing"

    Upon save.

    Is your question about the editor not displaying a more useful error message or are you expecting the syntax to be valid?

    Just asking for clarification (I don't work on the project)

  2. Scott Wells repo owner

    To build on what Eric said, IC has its own Apex/SOQL/SOSL parser and what you're seeing is feedback from it when the provided text doesn't adhere to its grammar. Due to the complexity of building and maintaining a parser for languages for which no published grammar exists, there are occasionally issues that need to be addressed. As Eric states, sometimes these errors do flag invalid syntax but they don't produce the same type of message that the server would produce when you try to deploy.

    Having said that, I just tried to reproduce this error using a standard object and was unable to do so. For example, in the following:

    List<AggregateResult> accounts = [
        SELECT AccountSource acctSrc
        FROM Account
        GROUP BY AccountSource
    ];
    

    there are no flagged errors and the query executes just fine. Can you provide a reproducible test case based on standard objects and fields so that I can look into it?

  3. Eric Alexander

    @RoseSilverSoftware Typing this exactly in the editor produces the error

    Account a = [Select Name team From Account];
    

    However, this does not, strange

            Account a = [Select Name myAlias From Account];
    

    Seems it has something to do with the keyword team

  4. Scott Wells repo owner

    Doh! I'm running on a 2.0 beta where this is already fixed. That's why I'm not seeing it. Okay, I'll take a look and see if I can integrate the specific fix for this back into the current product.

  5. Phil W reporter

    Sorry I didn't get back to you yesterday. The original posting shows that I was using GROUP BY, thereby enabling the option to provide an alias. Good that Scott has figured out that the issue does have a fix :)

  6. Eric Alexander

    The issue is specifically with the team alias.

    This also produces the error

    AggregateResultsList[] ar = [SELECT Team__c team FROM Shift__c Group By Team__c]
    

    Where

    AggregateResultsList[] ar = [SELECT Team__c teams FROM Shift__c Group By Team__c]
    

    does not

  7. Phil W reporter

    Eric,

    Interesting. I wonder if it is the text or the length of the text that is key here?

    Phil

  8. Eric Alexander

    Its not the length as other words with same length do not throw the error...

    I believe it is specifically the word team.

  9. Phil W reporter

    Don't think "team" is a reserved word. Could it be because it is the root of the custom property name? Team__c and team. I wonder if Shift__c and shift would cause the same issue? Anyway, Scott mentioned that he has a fix that he will see if is something he could back-port.

  10. Scott Wells repo owner

    Yup, the problem is that team is a reserved word as part of the SOQL clause USING SCOPE TEAM. However, as with many other reserved words in Apex/SOQL/SOSL, it's also allowed as an identifier. I already have a way to whitelist reserved words as identifiers, though I do so quite conservatively. I'll add team to the whitelist.

  11. Log in to comment