Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Thu, 19 Jul 2007 15:47:11 +0530
From: V.Narayanan@Sun.COM
Subject: Re: DERBY-581 and OLAP operations
In-reply-to: <86d8a57b0707190202v71519108rc873696f9850f8c4@mail.gmail.com>
Sender: V.Narayanan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <469F3A27.3050503@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <469E38A6.9060402@amberpoint.com> <469EA442.5040900@apache.org>
 <86d8a57b0707190202v71519108rc873696f9850f8c4@mail.gmail.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109

Hi,

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.

http://wiki.apache.org/db-derby/ForNewDevelopers.

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,

Narayanan


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.
>
>