[jira] [Comment Edited] (PHOENIX-1660) Implement missing math built-in functions

["James Taylor (JIRA)" <ji...@apache.org>]

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

James Taylor edited comment on PHOENIX-1660 at 2/19/15 5:41 PM:
----------------------------------------------------------------

Glad to hear you're interested, [~akki]. IMHO, a good way to start is to implement a built-in function. See the step by step instructions in the original description. You don't need to know the guts of the system in order to do this, as there are clear abstractions that you'll work against.

Phoenix is pretty big, so you won't find a document describing everything. Here's the 30,000 ft view:
- entry points are the classes that implement the JDBC API: PhoenixConnection, PhoenixStatement, PhoenixResultSet, PhoenixDatabaseMetaData.
- basic flow is parse->compile->execute:
    - parse query/statement (uses ANTLR - see PhoenixSQL.g grammar file) and builds object model (see ParseNode and its descendants).
    - compile query (see QueryCompiler and ExpressionCompiler). Makes extensive use of visitor pattern (see ParseNodeVisitor and descendants). The output of this phase is an executable query plan (see QueryPlan and descendants) with expressions that may be serialized/deserialized (to push them to the server) and evaluated (see Expression and its descendants). Essentially the ExpressionCompiler converts the ParseNode tree to an Expression tree while its doing validation.
   - execute query - modeled as nested iterators (see ResultIterator and descendants) with the top level iterator gotten from the QueryPlan. As much work is pushed to the HBase region server as possible through a custom filter (see BooleanExpressionFilter) and coprocessors (see BaseScannerRegionObserver).
- metadata is also available through Connection.getMetaData(). See PhoenixDatabaseMetaData which implements this interface and backs a "system" Phoenix table named SYSTEM.CATALOG which is where the metadata is stored.
- interaction with HBase server encapsulated in ConnectionQueryServices interface. See ConnectionQueryServicesImpl for implementation.


was (Author: jamestaylor):
Glad to hear you're interested, [~akki]. IMHO, a good way to start is to implement a built-in function. See the step by step instructions in the original description. You don't need to know the guts of the system in order to do this, as there are clear abstractions that you'll work against.

Phoenix is pretty big, so you won't find a document describing everything. Here's the 30,000 ft view:
- entry points are the classes that implement the JDBC API: PhoenixConnection, PhoenixStatement, PhoenixResultSet, PhoenixDatabaseMetaData.
- basic flow is parse->compile->execute:
  - parse query/statement (uses ANTLR - see PhoenixSQL.g grammar file) and builds object model (see ParseNode and its descendants).
  - compile query (see QueryCompiler and ExpressionCompiler). Makes extensive use of visitor pattern (see ParseNodeVisitor and descendants). The output of this phase is an executable query plan (see QueryPlan and descendants) with expressions that may be serialized/deserialized (to push them to the server) and evaluated (see Expression and its descendants). Essentially the ExpressionCompiler converts the ParseNode tree to an Expression tree while its doing validation.
 - execute query - modeled as nested iterators (see ResultIterator and descendants) with the top level iterator gotten from the QueryPlan. As much work is pushed to the HBase region server as possible through a custom filter (see BooleanExpressionFilter) and coprocessors (see BaseScannerRegionObserver).
- metadata is also available through Connection.getMetaData(). See PhoenixDatabaseMetaData which implements this interface and backs a "system" Phoenix table named SYSTEM.CATALOG which is where the metadata is stored.

> Implement missing math built-in functions
> -----------------------------------------
>
>                 Key: PHOENIX-1660
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1660
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>              Labels: Java, SQL, gsoc2015, mentor
>
> Take a look at the typical math functions that are implemented in relational database systems (http://www.postgresql.org/docs/current/static/functions-math.html) and implement the same for Phoenix in Java following this guide: http://phoenix-hbase.blogspot.com/2013/04/how-to-add-your-own-built-in-function.html
> Examples of missing functions include POWER, LOG, EXP, SQRT, CBRT, etc. As a guide, examine how ROUND is implemented in Phoenix as an abstract function with concrete functions per type: long, decimal, and date/time types.



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