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]

 



Hi,

On 4 Sep 2011, at 11:34, Colin Guthrie wrote:

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

Although not directly related, I used to work on a mail server (Scalix) that periodically updated its database format using (2).

You captured the problems that we had with the two approaches very well.  For the mail server, the cost of converting on the fly every time outweighed the cost of doing a conversion once on the first access quite substantially.   There was a period just after the upgrade when things ran slightly slower although this could be avoided by scanning the entire database (an fsck-like operation).

However, performance issues aside (which don't apply in this case) there was one huge advantage: subsequent upgrades had nicely separated code.   Given an item in the database (in Scalix's case) to get from version N to version M simply involved calling the each of the conversions from N, N+1, ? N+M-1 in order.  Once we decided that no one in their right minds would ever be using version N any more retiring it from the code base was basically "rm".   In your case you can keep the old code until it no longer compiles :-)

Based on my experience with Scalix, I'd vote for (2) every time.

jch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110904/1106724b/attachment.htm>


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

  Powered by Linux