[ 
https://issues.apache.org/jira/browse/PHOENIX-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-1646:
----------------------------------
    Attachment: PHOENIX-1646.patch

[~tdsilva] - would you mind giving this a quick review? It looks bigger than it 
is. Basically, instead of going through Expression to get the string, we go 
through ParseNode (which necessitated adding the toSQL method every where). The 
reason is that otherwise we have the potential for losing information - namely 
stuff that's optimized into constants during compilation. Although it'd be 
possible to change that, it'd be more difficult and riskier that this change. 
We pass the ColumnResolver through so that we can fully qualify column 
references. We also support a null for ColumnResolver if this doesn't matter, 
but for views and functional indexes, we want to fully qualify them (in case 
they become ambiguous later).

Now, functionally you can reference date constants in functional expressions 
and views and current_date() in views. I also added tests in QueryParserTest, 
WhereOptimizerTest, and WhereCompilerTest that asserts being able to go from 
ParseNode -> String -> ParseNode without losing any information.

> Views and functional index expressions may lose information when stringified
> ----------------------------------------------------------------------------
>
>                 Key: PHOENIX-1646
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1646
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>         Attachments: PHOENIX-1646-wip.patch, PHOENIX-1646.patch
>
>
> We currently produce a string from an Expression to store in the system 
> catalog for views and functional indexes. However there are a number of 
> constructs that won't roundtrip correctly, mainly due to the way expression 
> trees get collapsed during compilation. The easiest way to fix this is to go 
> from the ParseNode to a string instead and fully resolve column names in the 
> process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to