Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 01 Jul 2008 12:52:41 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: simpler api to the Derby store
In-reply-to: <486A6E52.8000800@sbcglobal.net>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <486A8B09.7010106@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <4863BD11.5050402@sun.com> <4863C0CD.6070303@amberpoint.com>
 <486A6E52.8000800@sbcglobal.net>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)

Hi Mike,

Thanks for responding. Some comments inline...

Mike Matrigali wrote:
> Bryan Pendleton wrote:
>>> be useful for applications which just need to put and get data by 
>>> key value. These would be applications which don't need complex 
>>> queries or SQL. 
>>
>> Aren't there some pretty good packages for this already? E.g., BDB-JE,
>> JDBM, Perst, etc.?
>>
>> Speaking totally personally, I'd sure like to see Derby focus on the
>> things that make it special:
>>  - complete and correct JDBC implementation
>>  - complete and correct SQL implementation
>>  - low footprint, zero-admin reliable multi-user DBMS
>>
>> thanks,
>>
>> bryan
>>
> I agree with bryan, I would rather see the Derby project concentrate on
> the stated goals of the project as Bryan enumerates.
>
> I do wonder if within this scope derby could do a better job of 
> addressing the application paradigm of only needing single keyed
> access to a row of the form (short key, short data).  By being embedded
I think that there are other usage patterns which are important to 
people who use these btree stores. It's not just single row key/value 
lookup although that's an important case. People also like to position 
an iterator on a btree and then march forward (or backward), updating 
and deleting as they go.
> derby already presents a better solution for a java application than
> a lot of databases.  So issues are:
> 1) can we improve the jdbc implementation to make using it for a 
> compiled plan close to as efficient as a non standard, store specific 
> interface?  And if jdbc is too complicated, could something very simple
> be provided on top of jdbc at the cost of an extra method call per
> access?
I think these are useful itches to scratch. Just to repeat the benefits 
of Derby Lite:

i) smaller
ii) faster
iii) easier

Streamlining the JDBC and SQL interpreter stacks would give us something 
faster but not smaller or easier.

There are already plenty of ORM layers which you can bolt on top of 
Derby in order to get something that is easier but bigger. I think that 
the ORM layers can deliver something faster too but at the cost of 
warming up a cache.

> 2) Can we provide a way such that only a single btree need be created, 
> rather than the current requirement of a heap and index.  The current
> model works well if one needs to create multiple indexes on the base
> data, and if there is is no limit on the size of the un-indexed portion
> of the data.
Other relational databases support this structure.  If we were just 
building this for Derby Lite, then some of the issues are called out at 
http://wiki.apache.org/db-derby/DerbyLite#head-6d68dc7584419d1853f1f15d203513afa44be3a6 
:

a) The current payload in the btree leaf page is a RowLocation and there 
may be some other assumptions about this payload, for instance as you 
note, its size.

b) Row-level locks are held on heap rows, not btree entries.

I could definitely see this improvement being built by the Derby Lite 
enthusiasts. Then someone else could come in and add support for it in 
the Derby SQL interpreter.

Thanks,
-Rick
>
> 3) anything else?
>