RFC: Database formats on upgrade - auto-convert and save or just auto-convert

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/9/4 Colin Guthrie <gmane at colin.guthr.ie>:
> Hi,
>
> Generally speaking we'll try and not write stuff to disk if the user
> does not trigger a change.
>
> Currently in git master, if we encounter a legacy database format, we
> convert it on the fly and then *write it to disk*.
>
> We could avoid the writing to disk without any operational issue (if the
> user changes the data it will be saved in the new format quite happily).
>
> The problems are that when we eventually remove support for legacy
> format databases, if the user has not adjusted his saved values for a
> while, they will ultimately be lost at that point in the future. If we
> convert and save to disk, he is "safe".
>
> But writing to disk immediately has it's own risks: I just fixed a bug
> in the conversion process of stream-restore for example that basically
> wiped out that database - oops. I've now done quite a few tests and all
> seems well, but all the same this does carry some "risks".
>
> What do you think the best route forward here is?
>
> ?1. Convert on the fly only.
> ?2. Convert on the fly and write to disk.
>
> Vote now!

2.

I'm not too worried about preserving stored values either way
actually. It's just user preferences, moreover, they are implicit
preferences, only resulting from volume change or moving of a stream.
In my opinion that's not so valuable as to make significant effort to
protect it in some rather uncommon scenarios. (downgrading to pulse
using previous db format or severe bug in db handling code)

Maarten


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux