Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 85894 invoked from network); 29 Dec 2006 16:43:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Dec 2006 16:43:00 -0000 Received: (qmail 61324 invoked by uid 500); 29 Dec 2006 16:43:05 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 61302 invoked by uid 500); 29 Dec 2006 16:43:05 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 61291 invoked by uid 99); 29 Dec 2006 16:43:05 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Dec 2006 08:43:05 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: 32.97.110.149 is neither permitted nor denied by domain of Stan.Bradbury@gmail.com) Received: from [32.97.110.149] (HELO e31.co.us.ibm.com) (32.97.110.149) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Dec 2006 08:42:53 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kBTGgTmJ003353 for ; Fri, 29 Dec 2006 11:42:29 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBTGgTN1450114 for ; Fri, 29 Dec 2006 09:42:29 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBTGgT6k024272 for ; Fri, 29 Dec 2006 09:42:29 -0700 Received: from [127.0.0.1] (sig-9-49-135-19.mts.ibm.com [9.49.135.19]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBTGgRPK024114 for ; Fri, 29 Dec 2006 09:42:28 -0700 Message-ID: <45954567.1000008@gmail.com> Date: Fri, 29 Dec 2006 08:42:15 -0800 From: Stanley Bradbury User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Derby Discussion Subject: Re: renaming columns References: <200612291239.14515.ralf.wiebicke@exedio.com> <4595088F.5010804@sun.com> <200612291354.00191.ralf.wiebicke@exedio.com> In-Reply-To: <200612291354.00191.ralf.wiebicke@exedio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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.