db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Schatten <ala...@gmx.at>
Subject Re: Frustration: lack of alter table functionality
Date Mon, 11 Dec 2006 17:02:07 GMT
yes, that works for sure, however, I think that this is far too 
expensive, that I do not even want to think about it. Actually with 
hsqldb such operations are a matter of seconds, not to speak of the 
flexibility to work with the script file. And not to think of the case, 
when I have to upgrade databases "in the wild".

however, I still hope, that Derby will support this soon, because I 
really think this is an extremly important feature, as every database I 
know supports this.

and I fear, many users will be damn disappointed and frustrated (as I 
was) when they have some work invested into a schema and then realise 
this lack of functionality (because actually I could not believe, that 
any database would not support this).

And it is really  a pity, as Derby has great functionality and then is 
(at least for me) practically not usable by this reason.


thanks anyway



Alex

Paul J DeCoursey wrote:
> Alexander Schatten wrote:
>> thank you for your hints, I was doing something similar with huge 
>> effort, but after this experience, I invested some hours and switched 
>> back to hsqldb, this is---sorry to say---by far more convenient for 
>> development purpose. similar restructuring with hsqldb took me 
>> seconds. It is really impossible to develop with a database, where 
>> restructuring is not feasible, and at the moment I have to say, it is 
>> even worse to roll out with a database under such conditions.
>>
>> I think I wait for the next release and will then probably change 
>> back to Derby. the hsqldb concept with the script file is just 
>> perfect for development issues.
>>
>> I really hope for the next release of Derby...
>>
> Maybe I'm in the minority but I've never had issues.  While in 
> development I never do alter tables, I drop the entire database and 
> rebuild the entire thing including test data using scripts. It's far 
> easier and I can ensure that it will react as if a new install each 
> time. I also put a lot into testing and planning to be sure that my 
> final results will not need altering after deployment. And when it has 
> come up where I needed to alter something after deployment I build a 
> new database and copy data into it.  That isn't ideal, but it's clean.
>
> Paul
>


Mime
View raw message