On Tue, May 12, 2009 at 23:50, Hyrum K. Wright
> On May 12, 2009, at 4:42 PM, Greg Stein wrote:
>> On Tue, May 12, 2009 at 23:03, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>> On May 12, 2009, at 3:12 PM, Greg Stein wrote:
>>>> Hi all,
>>>> I'm planning to bump the format from 12 to 13 tomorrow.
>>>> Formats 1..11 will require a manual 'svn upgrade'
>>>> Format 12 will be automatically/silently upgraded to 13
>>>> The code is almost there, but I'll be fine-tuning some of the upgrade
>>>> detection and responses before the format bump.
>>>> If you have any questions or concerns... then let's hear it!
>>>> Rationale behind the bump:
>>>> - rationalize our dav_cache storage (aka wcprops)
>>>> - add the work queue (replacement for loggy)
>>> remove incomplete flag on BASE nodes?
>> Sure, that too. Just not a driving rationale.
>> ps. and no, it can not be "removed", as sqlite does not support column
>> removal in "alter table" statements
> Sure, but what about something like this (from the FAQ)?
> BEGIN TRANSACTION;
> CREATE TEMPORARY TABLE t1_backup(a,b);
> INSERT INTO t1_backup SELECT a,b FROM t1;
> DROP TABLE t1;
> CREATE TABLE t1(a,b);
> INSERT INTO t1 SELECT a,b FROM t1_backup;
> DROP TABLE t1_backup;
Ah. Hadn't seen that workaround.
Given that our format upgrade system runs through all SQL statements
between format N and format M, then I don't think we'd want to rebuild
tables many times during a single upgrade. How about if we drop
columns in some future upgrade? I suspect the "collapse into
single-db" will be a fine point for tossing columns (and possibly a
large revamp of the upgrade tweaky processes).
Received on 2009-05-13 00:00:38 CEST