Hi Rick, I've tried following up with this because I'd be interested in using this lighter version. From what I've been able to find, it looks like you started to set up the goals for such an effort. Is this effort still moving forward?
My chief need would be speed -- factoring out the overhead of the JDBC/SQL interface. I see someone else noted that this has been measured at 15-20% for lookups on simple tables. I would definitely use the subsystem to get a 20% improvement when using an embedded database. Brian -----Original Message----- From: richard.hille...@sun.com [mailto:richard.hille...@sun.com] Sent: Monday, January 05, 2009 9:49 AM To: Derby Discussion Cc: derby-...@db.apache.org Subject: Re: is there a lower-level (non-SQL) API for Derby? Hi Tim, This question has come up before. For instance, you may find some interesting discussion on the following email thread: http://www.nabble.com/simpler-api-to-the-Derby-store-td18137499.html#a181374 99 The Derby storage layer is supposed to be an independent component. The api is described in the javadoc for the org.apache.derby.iapi.store.access package: http://db.apache.org/derby/javadoc/engine/ What would you say are your chief needs? Are you looking for a version of Derby which is 1) smaller 2) faster or 3) easier-to-use Hope this helps, -Rick Tim Dugan wrote: > > I'm looking to see if Derby can be used similarly to Berkeley DB -- a > lower-level API. Can anyone tell me? > > > > Maybe to the access area of the "Store Layer" which in some Derby > documentation is described like this: > > "The Store layer is split into two main areas, access and raw. The > access layer presents a conglomerate (table or index)/row based > interface to the SQL layer. It handles table scans, index scans, > index lookups, indexing, sorting, locking policies, transactions, > isolation levels." > > Now that Derby is included in Java 16--I am having a really hard time > finding Java documentation that talks about Derby. >
