db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbyLite" by RichardHillegas
Date Mon, 30 Jun 2008 20:58:13 GMT
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. ||
  
  
  

Mime
View raw message