db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivo Jimenez" <ivojime...@gmail.com>
Subject Re: DERBY-581 and OLAP operations
Date Thu, 19 Jul 2007 09:02:58 GMT

I'm new to Derby and I'd like to contribute. Casually, my interests are on
OLAP, so its great to read your proposition of adding this kind of features.
I have experience in Java and Databases but I don't know if there's a
certain level of knowledge that a contributor has to get in order to help
with coding. Should I start by doing things less sensible? Or doing another
kind of work?

I could start by helping with the literature exploration and adding content
to the Wiki, as Bryan mentioned. I'd also like to code! So I'd be very happy
to be the second person that Manish pointed.

Just to complement, as far as I know the OLAP extensions were annexed to SQL
on the 1999 standard (http://www.jcc.com/sql.htm) by annexing the CUBE and
ROLLUP operators (paul.rutgers.edu/~aminabdu/cs541/*cube*_op.pdf).


On 7/18/07, Daniel John Debrunner <djd@apache.org> wrote:
> 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.

View raw message