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

[Damyan Ivanov]

Kai Bäsler wrote:
> 
> Am 09.06.2006 um 13:31 schrieb Damyan Ivanov:
> 
>> Finally someone other tham me is posting here :)
> 
> You're not alone here ;-)

This is very good to know. Thanks for your support.

>> 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 am verry interrested of the results of your tests. Especially since
you have identified a possible conflicting keyword. I must finally
find some time and test this issue throughly.

Generally, I think we can be OK if 2.0 server is working with
1.5-created databases even with limited capabilities.

It would be fine if this approach is possible:
1) forget about separate packages for 2.0 servers
2) 2.0 server can read 1.5 databases
2.1) 2.0 packages convert security.fdb to security2.fdb on upgrade
   (with big warning, since this conversion can't use advanced
password hashing used in security2)
3) admin checks new updatable view semantics and fixes them appropriatelly
4) admin checks for conflicts with new keywords
5) admin makes a backup and restores to *different* location
if 5) gives errors, go to 3) and 4) and repeat
6) happy, happy admin uses 2.0 and moves old databases away

For this to happen, 2.0 server must be able to work (manipulate
metadata and take backup) of 1.5 database - and this is something that
needs testing. I'll do it with a copy of out 19G production database
and report (within a couple of weeks).
It is also important that no automatic ODS upgrade is done when 2.0
server works with 1.5 database, because if admin decides to get back
to 1.5, the database would use unsupported ODS.

This reminds me of another possible problem. What if 1.5->2.0 move is
not completely ok and admin wants to go back and continue using 1.5?
(Restore pre-upgrade backup is a possible solution, but kind of
non-optimal)

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

My idea was that leaving 1.5 listening on non-standard port is only
temporary until databases are migrated. Something like the following:

-1) ... friday ... noone is suspecting anything
0) ...saturday morning...
1) install 1.5 listening on 3060
2) install 2.0 listening on 3050
3) make 1.5 databases compatible with 2.0 and take a backup (all this
using 1.5 server on port 3060)
4) restore on 2.0
4a) in case of a problem, go to 3)
5) ... monday morning ...
6) all client applications happily work with 2.0 server and converted
databases on the same standard port 3050
7) sysadmin takes a long vacation on a desert island :)

Perhaps all this may be made selectable on install. Something like:
,----------
|   What version of firebird do you want running on default port?
|
|   ( ) 2.0
|   ( ) 1.5
`-----------
Similarly to XDM selection.

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

Unfortunatelly firebird can't bind to specific interface, AFAIK.


So all in all, I am still not sure which approach to take:
1) separate packages, servers listen on different ports
2) on-the-fly upgrade

1) seems the safer
2) is simpler, but requires more testing

Right now I am going with 1), but this can easyly be reverted to 2) if
that proves to be safe.

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

Okay. Understood. Happy footballing :)


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/68db3b76/signature.pgp