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

Damyan Ivanov dam at modsoftsys.com
Fri Jun 9 11:31:56 UTC 2006


Hi, Francesco, Kai,

Finally someone other tham me is posting 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

>> 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.

And I like the idea of co-installability because this will give users
room and flexibility to do the transition on their own without force.

The only discomfort I see is in my plan for avoiding listening port
conflicts and client binaries clashes (gbak etc).

I plan to make fb1.5 listen on port 3060 by default and in fact make
2.0 the default firebird (on port 3050). There will not be database
clashes (initially), since fb2.0 will use separate configuration and
database directories.

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. Not that
installing a couple of packages is a problem, but it is a bit
uncomfortable (IMHO).

I just have to check if client binaries (isql/qli/gbak/gfix etc,
without gsec) from 2.0 can work with 1.5 server. This would elliminate
two packages and version-detection hackery (a-la postgre) from the
equation, leaving only server-packages version-specific.


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


Best regards,
dam
-- 
Damyan Ivanov                           Modular Software Systems
dam at modsoftsys.com
phone +359(2)928-2611, 929-3993              fax +359(2)920-0994
mobile +359(88)856-6067             dam at jabber.minus273.org/Gaim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-firebird-general/attachments/20060609/4f2a002c/signature.pgp


More information about the pkg-firebird-general mailing list