db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From V.Naraya...@Sun.COM
Subject Re: DERBY-581 and OLAP operations
Date Thu, 19 Jul 2007 10:17:11 GMT

Welcome to derby!

If you are confident of the issue you want to work on feel free to start 
working on a JIRA issue.

But if you think you need to start with some simple issues and then move 
on to the issues
you think are a little bit more complicated this page contains lot of 
information on how to
start-up with the development process.


The same page also explains how you can choose simple issues to start 
working on.

Also pls do post any queries or doubts in the development process to 
derby-dev@db.apache.org ,
you are sure to get responses.

Hope this helps,


Ivo Jimenez wrote:

> Hi,
> 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 
> <http://www.jcc.com/sql.htm>) by annexing the CUBE and ROLLUP 
> operators (paul.rutgers.edu/~aminabdu/cs541/ 
> <http://paul.rutgers.edu/%7Eaminabdu/cs541/>*cube*_op.pdf).
> Cheers,
> Ivo
> On 7/18/07, *Daniel John Debrunner* <djd@apache.org 
> <mailto:djd@apache.org>> wrote:
>     Bryan Pendleton wrote:
>     > In the context of
>     https://issues.apache.org/jira/browse/DERBY-581
>     <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