db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: renaming columns
Date Fri, 29 Dec 2006 16:42:15 GMT
Ralf Wiebicke wrote:
>> Note that 10.2.2 is made from another svn branch than the development
>> branch (trunk).  Revision numbers on different branches are not directly
>> comparable.
>>     
>
> [slap-on-forehead]
> Thanks for the hint.
>
> I'm wondering, that such a fundamental feature is not yet available in the 
> latest release. I noticed derby, because its included in Java 6. So I 
> thought, it's mature enough to support it in my project. All other databases 
> I use do support renaming columns. I'm not yet sure, whether I want to work 
> around this problem, or wait for the next release.
>
> Best regards,
> Ralf.
>
>   
Hi Ralf -
I'm glad to see that you are taking Derby for a test drive.  Being 
included in latest JAVA release will  introduction Derby to a much wider 
audience than ever before.  One thing that you and others will notice 
about Derby is that it is not just a database of a different color, 
notably it has a very small footprint and so lacks some out-of-the-box 
features of larger, mainstream systems.  This can cause some 
frustration.  A little background will help you understand and possibly 
anticipate some of the differences between Derby and other databases.  
The software was first released in 1997 by Cloudscape Inc. as a product 
called JBMS.  In his article / tutorial Pan Pantziarka provides a brief 
history of the software at:    
http://www.regdeveloper.co.uk/2006/11/08/java_database_derby/

JBMS (later renamed Cloudscape) was designed primarily for embedded use 
hence the lack of features (thought of as administrative) such as 
RENAME, GRANT/REVOKE, etc.  The underlying engine, however, is very 
solid and easy to deploy and use.  Currently many of these useful 
features are being added by the Derby development community with minimal 
impact of the software footprint.  And, as you can see from the 
following list of software, Derby in it's current state is the choice on 
many software projects because of it's portability and ease of use in 
production environments:
               http://wiki.apache.org/db-derby/UsesOfDerby

In the meantime, even though these differences can prove frustrating, I 
hope you will keep your eye on the product and provide additional 
feedback on the features you consider important but lacking in Derby.


Mime
View raw message