[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2541) no-arg function inside "vector expression" not properly replaced with Dialect function mappings

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_26625 ] 

Steve Ebersole commented on HHH-2541:
-------------------------------------

grrr

Unfortunately I do not see how this is possible with the current grammars because because of the current addrExpr rule and how it works (causes non-determinism).  I think I would need to pull over the notion of selectExpr as it is being handled in the redesigned grammars from a recognition perspective.  The resolution piece would need to remain the same (if that is possible).  

So actually this may end up being a lot of work to introduce a proper fix into the current grammars.

> no-arg function inside "vector expression" not properly replaced with Dialect function mappings
> -----------------------------------------------------------------------------------------------
>
>                 Key: HHH-2541
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2541
>             Project: Hibernate3
>          Issue Type: Bug
>          Components: query-hql
>            Reporter: Steve Ebersole
>            Assignee: Steve Ebersole
>            Priority: Minor
>
> For an example of this, see org.hibernate.test.component.basic.ComponentTest#testComponentQueries against a Sybase database.  
> The issue is the third query in that test: from Employee e where e.person = ('steve', current_timestamp)
> The first grammar (hql.g) is currently the one responsible for deciding whether an IDENT node represents a METHOD_CALL.  However, it currently does this by seeing if the IDENT is immediately followed by an '('.  Here, the current_timestamp method call is not because it is no-arg and so hql.g does not retask the IDENT as a METHOD_CALL.  And actually this is correct.  The code in hql.g is simply trying to get the common case.  And we do not want to blindly look up the IDENT text in the Dialect to see if it matches a mapped function name (because it might also represent a property name, which should take precedence).
> The solution is to account for this in the second grammar (hql-sql.g) during recognition of a vector expression.  Actually, the correct correct solution is better precedented recognition of atomic expressions...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira