Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Mon, 30 Jun 2008 20:58:13 -0000
Message-ID: <20080630205813.28930.94065@eos.apache.org>
Subject: [Db-derby Wiki] Update of "DerbyLite" by RichardHillegas

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by RichardHillegas:
http://wiki.apache.org/db-derby/DerbyLite

------------------------------------------------------------------------------
  
  == API ==
  
- Here we can brainstorm what this API looks like at a high level.
+ It would be great if we could add a lean package to Derby, which exposed a small set of concepts and then mapped between those concepts and the richer api in org.apache.derby.iapi.store.access. For starters, the lean api package could model these concepts:
+ 
+ || '''Concept''' || '''Description''' ||
+ || '''Database''' || This would be a collection of BTrees operated by a connected user. Maybe we would also need to model the concepts of session and Database factory, but it would be interesting to see how far we could get with just a simple Database container. ||
+ || '''Types''' || We might be able to do without the concept of a type system. We could, for instance, decide that we will only support opaque byte arrays as the types of keys and values. Other, similar products seem to operate this way. However, it seems a shame to not expose Derby's ability to handle complicated, multi-column keys, each component of which can be sorted ascending or descending independently of the others. It ought to be cheap to maintain this differentiating feature. A first release wouldn't necessarily have to expose the full complexity of the types we support. We could, for instance, get away with just supporting two types, which correspond to VARBINARY and LONGVARBINARY. The first could be used in keys and values. The second could only be used in values. Later on, we could add other types like INT, BIGINT, DOUBLE, DECIMAL, etc.. ||
+ || '''Tuple''' || This would a wrapper around keys and values. Again, we could probably omit this concept if we just wanted to support byte arrays as the only type for keys and values. If we wanted more complicated keys and values, then a Tuple would be a nice abstraction. A Tuple would be a sequence of typed values. ||
+ || '''BTree''' || This would be a persistent btree. It would hold keys in intermediate nodes. It would hold values in leaf nodes. You would get a BTree from a Database. ||
+ || '''Transaction''' || This would be used to commit and rollback work. You would get a Transaction from a Database and you would use it in operations on BTrees. ||
+ 
+ The following concepts turn up in other, similar products but we may not need them:
+ 
+ || '''Concept''' || '''Description''' ||
+ || '''Comparator''' || This is a scheme for ordering opaque byte arrays. This helps compensate for the fact that other products don't let you split the key value into independently orderable columns. There is not much need for this if we support multi-column keys. In addition, it seems that we ought to be able to realize some performance benefits by not having to serialize and deserialize keys for use by Comparators.  For truly opaque byte arrays, the lexicographic ordering of Derby VARBINARY may be good enough.||
+ 
+ As extra credit, in a later release, or in an add-on package, we could add the following:
+ 
+ || '''Additional Work''' || '''Description''' ||
+ || '''Serializer''' || We could add machinery to help users de/serialize Java objects from/to opaque byte arrays and extract key Tuples from Java objects. ||
+ || '''Qualifier''' || We could add some simple abstraction on top of the current Qualifier interface so that users could push simple qualifications into the store. ||