Thanks Narayanan! I'll go through the contents of the link you pointed, experiment a little bit and then will go the the JIRA issue as you suggested.
Good to know that Thomas is also joining! Regards, Ivo On 7/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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 [email protected] , 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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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. > >
