phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3355) Register Phoenix built-in functions as Calcite functions
Date Thu, 01 Dec 2016 23:47:58 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15713442#comment-15713442
] 

ASF GitHub Bot commented on PHOENIX-3355:
-----------------------------------------

Github user lomoree commented on the issue:

    https://github.com/apache/phoenix/pull/222
  
    1. No differentiation between the regex functions (String based and Byte based)
    Yep I'll try some approaches to make this work.
    
    2. Invert and MD5 Function don't work (phoenix doesn't supply the correct arguments in
annotation)
    Might be complicated. Phoenix uses a generic "term" as the input argument for these functions.
    See https://phoenix.apache.org/language/index.html#term
    We don't really have a type that encapsulates this kind of behavior as far as I know.

    This type of argument is represented by the following annotation:
    @BuiltInFunction(name = InvertFunction.NAME, args = { @Argument() })
    
    3. Timezone parameter doesn't work properly in ToDateFunction (basic cases work, but custom
timezones do not act as expected)
    I believe that's correct. When I was doing testing all of the results are inexplicably
off by an offset that is exactly the difference between UTC and and EST :)
    
    4. Type matching doesn't work on input arguments (date/timestamp)
    I explored this after our meeting. This used to be an issue in Calcite but was patched
about a year ago with the corresponding test cases added. When debugging these test cases,
I never touched the typePrecedence block that's an issue for us. Looks like I'll need to investigate
more.
    
    5. Array constructors are not supported (another issue entirely)
    Yes, I did make a jira for it, but perhaps we can expand it as you said.
    https://issues.apache.org/jira/browse/PHOENIX-3502
    
    6. Code refactoring:
    Having them in one spot is starting to make more sense; in that case, I agree that PhoenixSchema
would be the best location for everything. What I can do is having them ordered according
to how they logically progress, and have a comment block at the top that describes the behavior.

    
    In my opinion it's appropriate and reasonable to include 1, 3, and 6 in this pull request.
The other issues may take longer, and would postpone integrating this component.


> Register Phoenix built-in functions as Calcite functions
> --------------------------------------------------------
>
>                 Key: PHOENIX-3355
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3355
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Eric Lomore
>              Labels: calcite
>         Attachments: PHOENIX-3355.function_constructor.patch, PHOENIX-3355.wip, PHOENIX-3355.wip2
>
>
> We should register all Phoenix built-in functions that don't exist in Calcite.



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

Mime
View raw message