[pkg-firebird-general] [long] firebird 2.0 - and now what?

[Kai Bäsler]

Am 09.06.2006 um 13:31 schrieb Damyan Ivanov:

> Finally someone other tham me is posting here :)

You're not alone here ;-)




> Francesco Paolo Lovergine wrote:
>> On Fri, Jun 09, 2006 at 09:50:47AM +0200, Kai B?sler wrote:
>>>
>>> Your plan to have 1.5/2.0 in etch and 2.0 only in etch+1 sounds
>>> reasonable to me. I will always move to the current version, if i  
>>> can
>>> upgrade from one ODS to another with a simple gbak -T(ransportable).
>
> Not exactly, there are semantic changes and new keywords that may
> cause the backup not restore on 2.0
>

After skimming through the release notes i only found one possible  
conflict with my application, and that is the new reserved keyword  
'TRIM' which is curretly used in an udf.

The release notes for 2.0 RC also state "Although Firebird 2.0 will  
connect to databases
having older ODS versions, ...", so maybe i can run my application  
with the old ODS for a short period. I will definitely try it. I  
found this info at http://www.firebirdsql.org/rlsnotes20/rnfbtwo- 
general-notes.html


>>> I don't like the idea of installing both versions at the same time,
>>> because both want to bind to port 3050/tcp by default, and i don't
>>> want to go through the hassle of reconfiguring one (and remembering
>>> which version runs on which port). I think both versions should be
>>> mutually exclusive.
>>>
>>> Maybe we can help users to migrate with a little shellscript which
>>> automates the backup/restore process?
>>
>> Mmm, doing that at upgrade time could be _very_ error prone,  
>> potentially.
>> I personally avoid non-minimal changes to user data. A detailed  
>> upgrade
>> documentation is safer in many cases. A wrong assumption or a bug in
>> an upgrade script could be extremely dangerous.
>
> I also doubt we can create such a script. I see two problems with it:
> 1) finding all user databases
> 2) detect non-trivial changes that are needed for them to be
> 2.0-compatible
>  2.1) there are changes in semantics of view triggers that need
> careful examination
>  2.2) there are new keywords that need change/quoting
> 3) doing all this in prerm script. A backup process may run for hours
>
> These are the reasons I abandoned the idea of automatic upgrade.

I fully agree. This must not run automatically. Although it should be  
easy to catch more than 98% of all databases by looking at /var/lib/ 
firebird2/data and /etc/firebird2/aliases.conf.
And maybe we can convince more users to do a regular backup of their  
data, if we include a little cron fragment or example script for  
etch? I can certanily take one of my scripts and polish it a little bit.


> And I like the idea of co-installability ...
> I plan to make fb1.5 listen on port 3060 by default and in fact make
> 2.0 the default firebird (on port 3050). ..

This would make any application break seriously, when you are already  
running firebird. In my situation i would have to update 100+ Windows  
PCs in two cities (plus a few laptops) running proprietary software.  
That software expects to connect to port 3050. It's a real show stopper.
What if someone (or two different apps) looks up gds_db from /etc/ 
services? You can't patch every 3rd-party application to look for  
'gds_db_new'.


> I see very much value in the ability to both keep old 1.5 databases
> working while at the same time making experiments with 2.0. ...

I see your point, but i think this could make many users go crazy.  
The only reasonable way to have two different versions running on the  
same host is (IMHO) to bind to different ip-addresses.


> I can probably prepare some packages for testing this weekend. Anyone
> interested, please raise your hand :)

No need to hurry. Of course im interested, but i'm working for a  
company in the radio/broadcast sector, and the current soccer world  
championship here in germany keeps me busy for the next few weeks.

Kai