Bryan Pendleton wrote:
In the context of https://issues.apache.org/jira/browse/DERBY-581
I've been studying the SQL-99 standard's specification of
OLAP operations:
- Feature T611 specifies "Elementary OLAP operations"
- Feature T612 specifies "Advanced OLAP operations"
I'm interested in exploring an implementation of these features,
and to start with I'd like to get the community's reaction:
- Are these features that we're interested in seeing added to Derby?
If one person wants to scratch that itch then that's all that's
required. Go for it! :-)
- Are there others in the community who are interested in
working on these features?
- How could we approach this incrementally, building enough
functionality to be useful, arriving at a complete
implementation in pieces over time? For example, would it be
reasonable to build a subset of the T611 features at first,
and then expand that functionality over time? Would it be
reasonable to add new SQL syntax support, but have it work
only in a subset of cases, and then expand the execution
functionality over time to address more usages?
Sounds good, progress, not perfection. Just try to avoid committing
changes that result in working behaviour that might change in the
future, i.e. a subset of working functionality is a great way to start.
I was thinking that I might get started by trying to build
one or more Wiki pages that describe some of the materials
that might go into an implementation:
- background information about the features and the
concepts behind them
- notes about the current Derby implementation, and about
possible ways to extend the implementation in this area
- ideas for how to subdivide and stage the implementation,
in order to enable us to start talking about actual code.
I would encourage extending Derby in ways that enhance the code clarity.
For example, code might be cleaner by creating a new QueryTreeNode for
any new grouping functionality rather than more 'if' statements or other
complex logic in an existing GroupByNode. Or even cleaning up existing
nodes to allow sharing between various related nodes. E.g. move common
code from existing GroupByNode into an abstract node, and then have
multiple nodes that handle grouping operations extend from that.
Does this seem like a reasonable approach?
+1
Dan.
