[
https://issues.apache.org/jira/browse/DERBY-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16414891#comment-16414891
]
Rick Hillegas edited comment on DERBY-6991 at 3/27/18 12:42 PM:
----------------------------------------------------------------
It is a large, complicated codebase. The best place to start would be to study
the patches attached to DERBY-5466. Those are the classes which will need to be
touched in order to implement LISTAGG. You should also read the architecture
documents nested under "Derby Engine" under "Papers and Presentations" in the
left pane of the resources tab on the Derby website. See
http://db.apache.org/derby/papers/derby_arch.html
A relational database like Derby consists of a SQL interpreter on top of a
transactional file system. The SQL interpreter compiles a SQL statement and
then runs it against the transactional file system. The main processing phases
of a SQL interpreter are as follows:
1) Parsing - This is the task of converting a SQL query into an abstract syntax
tree (AST). The main class involved here is
java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj. That file is the
SQL grammar, written in JavaCC. See
java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
2) Binding - This is the task of resolving names and datatypes in the AST. This
task and the remaining compilation tasks are performed largely by the AST nodes
themselves. The AST nodes live alongside the grammar in
trunk/java/engine/org/apache/derby/impl/sql/compile. The main AST nodes
involved in implementing LISTAGG would be AggregateNode and
UserAggregateDefinition. All AST nodes descend from the superclass
QueryTreeNode. Methods with the word "bind" in them are the workhorses of the
binding phase.
3) Optimization - You don't have to worry about this phase. There are no
additional optimization decisions to make during the compilation of
user-defined aggregates.
4) Code-generation - Again, this task is performed by the AST nodes themselves.
In this phase, the AST tree is transformed into a graph of executable nodes
called the query plan. The executable nodes live in
java/engine/org/apache/derby/impl/sql/execute. The main class for implementing
LISTAGG is UserDefinedAggregator. Code generation is performed by methods with
the word "generate" in them.
5) Execution - The execution logic would be an implementation of
java/engine/org/apache/derby/agg/Aggregator.java.
Take some time to study these classes, the architecture docs, and the work
which was done on DERBY-5466. Feel free to ask lots of questions.
Thanks,
-Rick
was (Author: rhillegas):
It is a large, complicated codebase. The best place to start would be to study
the patches attached to DERBY-5466. Those are the classes which will need to be
touched in order to implement LISTAGG. You should also read the architecture
documents nested under "Derby Engine" under "Papers and Presentations" in the
left pane of the resources tab on the Derby website. See
http://db.apache.org/derby/papers/derby_arch.html
The main processing phases of a SQL database are as follows:
1) Parsing - This is the task of converting a SQL query into an abstract syntax
tree (AST). The main class involved here is
java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj. That file is the
SQL grammar, written in JavaCC. See
java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
2) Binding - This is the task of revolving names and datatypes in the AST. This
task and the remaining compilation tasks are performed largely by the AST nodes
themselves. The AST nodes live alongside the grammar in
trunk/java/engine/org/apache/derby/impl/sql/compile. The main AST nodes
involved in implementing LISTAGG would be AggregateNode and
UserAggregateDefinition. All AST nodes descend from the superclass
QueryTreeNode. Methods with the word "bind" in them are the workhorses of the
binding phase.
3) Optimization - You don't have to worry about this phase. There are no
additional optimization decisions to make during the compilation of
user-defined aggregates.
4) Code-generation - Again, this task is performed by the AST nodes themselves.
In this phase, the AST tree is transformed into a graph of executable nodes
called the query plan. The executable nodes live in
java/engine/org/apache/derby/impl/sql/execute. The main class for implementing
LISTAGG is UserDefinedAggregator. Code generation is performed by methods with
the word "generate" in them.
5) Execution - The execution logic would be an implementation of
java/engine/org/apache/derby/agg/Aggregator.java.
Take some time to study these classes, the architecture docs, and the work
which was done on DERBY-5466. Feel free to ask lots of questions.
Thanks,
-Rick
> GROUP_CONCAT
> ------------
>
> Key: DERBY-6991
> URL: https://issues.apache.org/jira/browse/DERBY-6991
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.15.0.0
> Reporter: The Alchemist
> Priority: Minor
>
> I was wondering what it would take to get {{GROUP_CONCAT()}} support.
>
> If someone points me in the right direction, I can send a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
