[ 
https://issues.apache.org/jira/browse/BEAM-4365?focusedWorklogId=104112&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-104112
 ]

ASF GitHub Bot logged work on BEAM-4365:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 21/May/18 16:36
            Start Date: 21/May/18 16:36
    Worklog Time Spent: 10m 
      Work Description: apilloud commented on issue #5433: [BEAM-4365] Make 
BeamSqlExpression for operators, use it for string operators
URL: https://github.com/apache/beam/pull/5433#issuecomment-390709460
 
 
   nit: All this code should be deleted. We tell the parser we support 
SqlStdOperatorTable, which is defined in Calcite. Along with that, there is a 
code generator that implements all these functions in Java. We should adapt it 
to generate doFns instead of Enumerable blocks. See: 
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableCalc.java

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 104112)
    Time Spent: 40m  (was: 0.5h)

> SQL operator argument evaluation should have one place where it is managed
> --------------------------------------------------------------------------
>
>                 Key: BEAM-4365
>                 URL: https://issues.apache.org/jira/browse/BEAM-4365
>             Project: Beam
>          Issue Type: Bug
>          Components: dsl-sql
>            Reporter: Kenneth Knowles
>            Assignee: Kenneth Knowles
>            Priority: Major
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> The way Beam SQL is factored, each operator has to explicitly ask its 
> argument to be evaluated. This should be handled generically at a higher 
> level. Since the language is pure and terminating, it is fine for them to 
> vary, but given the simplicity of the expression language it makes sense to 
> use simple call-by-value.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to