Re: [Sqlgrey-users] Patch: Configurable rejection

[Lionel B. <lio...@bo...>]

Michel Bouissou wrote the following on 17.02.2005 11:04 :

>Le Jeudi 17 F=E9vrier 2005 10:52, Lionel Bouton a =E9crit :
> =20
>
>>I'll release a 1.4.5 with this and the fixes we discussed since 1.4.4.
>>Then I think I'll move on 1.5.x beginning with database changes instead
>>of releasing them for the stable 1.4 series.
>>   =20
>>
>
>Would you consider integrating the index order changes in next 1.4x ? It=
 is=20
>important for sites having big SQLgrey DBs...
>
>I suggest that you could put 2 entries in the "config" tables : The curr=
ent=20
>one for the tables level, and maybe an "indexes" one that would only tak=
e=20
>care of indexes level.
>
> =20
>

What problem are you trying to solve with this separate index level entry=
 ?
If SQLgrey must take into account every possible combination of these=20
entries, this will become awfully complex.

>Because indexes can easily be dropped / recreated without having to touc=
h the=20
>rest of the DB structure...
>
>Anyway, if the indexes changes are not in 2.4.x, anybody who wishes to c=
hange=20
>them can do it manually directly on his SQL DB...
>
> =20
>
Yep.

Let me explain how I plan to make the changes. As renaming columns=20
(which will be done) is platform specific and creating indexes could=20
conflict with the ones created by the DBA, I'll simply *copy* the tables=20
into new ones and drop the original ones.
On big databases where the migration could take several seconds or even=20
minutes I'd suggest disabling the policy service until the convertion is=20
complete (will be logged). DBAs will have to recreate additional indexes=20
they might have created (if they are not created by the new db version).

At first I wanted to make this migration in 1.4.x but the number of=20
changes needed rised significantly. As I must make sure the three=20
supported RDBMS will migrate smoothly, I prefer to use 1.5.x for this.

Lionel.