db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dibyendu Majumdar <dibye...@mazumdar.demon.co.uk>
Subject Re: simpler api to the Derby store
Date Thu, 10 Jul 2008 22:58:15 GMT
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 <Knut.Hatlen@Sun.COM> 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?
>


Mime
View raw message