[
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)
