Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <469E38A6.9060402@amberpoint.com>
Date: Wed, 18 Jul 2007 08:58:30 -0700
From: Bryan Pendleton <bpendleton@amberpoint.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: DERBY-581 and OLAP operations
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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.

Does this seem like a reasonable approach?

thanks,

bryan