Making Derby architecture more modular

[Jean Morissette <je...@gmail.com>]

Hi,
    I developed a database front-end consisting mainly of a parser, a
type system, a type-checker, a logical algebra and an optimizer, for a
language similar to SQL.  I would happy if I could plug my front-end
with the Derby back-end, mapping my logical algebra with the Derby
physical operators.

However, it seems to me that the Derby architecture is not very
modular.  Indeed, IMO, Derby engine should be separated at least into
a front-end and a back-end, with well defined API.  The backend could
consist of the store, and the transaction mecanisms (locking, logging,
crash recovery).

Also, separating Derby engine into layers/components would decrease
the project complexity, helping newcomers.

Is there any plan to improve Derby architecture?

Regards,
Jean

Re: Making Derby architecture more modular

[Mike Matrigali <mi...@sbcglobal.net>]

The Derby Storage system was originally designed to be able to be
used standalone.  All calls to it go through java interface
routines defined in the following directory:
opensource/java/engine/org/apache/derby/iapi/store/access

More effort was put into the javadoc in that directory, as it is
intended to be the "well defined API".

Having said that, the Derby store has never actually been used
standalone.  So the interfaces have drifted to much more tightly
integrated with the needs of the specific Derby client modules, rather
than purely generic "store" interfaces.
And since it has never been used standalone I am sure an effort
to plug in a new front end would find some issues.

Other parts of the system are also very modular, and Derby has built
in support for dynamically loading alternate implementations of these
modules.  The store uses this ability to load and implement it's
current 2 storage structures and hopefully in the future allow alternate
index structures to be built.  I believe there are 2 implementations of
the optimizer.  Since going open source I believe some people have taken
the Derby parser and used it in their own projects.


Jean Morissette wrote:
> Hi,
>     I developed a database front-end consisting mainly of a parser, a
> type system, a type-checker, a logical algebra and an optimizer, for a
> language similar to SQL.  I would happy if I could plug my front-end
> with the Derby back-end, mapping my logical algebra with the Derby
> physical operators.
> 
> However, it seems to me that the Derby architecture is not very
> modular.  Indeed, IMO, Derby engine should be separated at least into
> a front-end and a back-end, with well defined API.  The backend could
> consist of the store, and the transaction mecanisms (locking, logging,
> crash recovery).
> 
> Also, separating Derby engine into layers/components would decrease
> the project complexity, helping newcomers.
> 
> Is there any plan to improve Derby architecture?
> 
> Regards,
> Jean
> 
>