Hi,
Here is my 2p worth:
1. The great thing about Apache Derby is that it is proven,
production strength code.
2. The code is already structured with the nice separation between
the Store and the
SQL engine.
Having a clean separation between the language and the Store layer
will give
several benefits:
a. It will allow multiple backend storage engines, such as in MySQL.
b. It will make Store itself reusable as a simple non-SQL persistence
engine.
I think that it would be wrong to start this as a fork of the
existing code base,
or to start creating a whole new API that is not native to Derby. To
start with,
it would be better if we could simply improve the separation of layers,
ensure that new developments do not introduce unwelcome dependencies,
maybe define standards that support the modular architecture. If this
could
be done, then the other benefits would automatically follow.
I raised DERBY-3450, DERBY-3405 and DERBY-3351 - all for the
purposes described above. Unfortunately, due to other pressures of my
day job, I haven't been able to devote time to this work in recent
months.
My experience so far is that there are some nasty dependency issues
in some areas which need to be sorted out. I was trying to do this
bottom
up - look at each module and try to remove dependencies, and work my
way up.
But it is hard going, and despite the excellent support from Dan and
others,
progress is quite slow. My current area of investigation is the
Exception
hierarchy - to remove EmbedSQLException (DERBY-3453) and just have
SQLException and sub-classes and StandardException.
It would be nice if others could join in in this effort - but as many
people
have pointed out, refactoring existing code is not really immediately
fruitful.
But I think that there are long term benefits that still make it
worth while.
Regards
Dibyendu
On 7 Jul 2008, at 16:40, Dag H. Wanvik wrote:
Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
although the API could need to be cleaned up and made easier. If
someone
wants to do such a cleanup, I think it would be good because
a) it may make Derby code that accesses the store simpler
(easier to
understand, more maintainable)
b) it is easier for other projects to use Derby's store directly
without needing to fork Derby's code base (which potentially
increases Derby's user base and the chance of getting contributions
back from those projects)
If the API were cleaner/easier, it would also make it more palatable
to produce other backends for Derby. We have had attempts to make main
memory backends; I am not sure why these never made it into
"production", though, could a backend API complexity be one reason?
