[PATCH 5/7] Re: Don't keep sqlite connections open

Nicolas Sebrecht nicolas.s-dev at laposte.net
Sat May 7 22:59:05 BST 2011

On Sat, May 07, 2011 at 07:08:35AM -0700, chris coleman wrote:

>    I bring this up because I see the project has been spending valuable
>    energy reinventing some basic database technology that already exists and
>    is tested by millions of users already-
>    a) flat files that are written to disk so often so they can play the role
>    of journaling and transaction logs - to prevent crashes from
>    losing/corrupting data.
>    b) cached local copy of a remote database index (this is what the
>    LocalStatus file is).
>    With the trend being toward larger and larger IMAP inboxes (unlimited
>    email storage available nearly everywhere), there are larger and larger
>    LocalStatus cache files.
>    The chances of crashing and losing/corrupting data in the middle of a
>    multi-megabyte write that takes place several times per second  - is going
>    to get bigger not smaller.
>    So, seriously, why not just let a proven reliable database handle the data
>    integrity concerns?  Even a 64MB laptop can run free mysql with room to
>    spare so it can't be because of system requirements...

It sounds wrong. Both MySQL and SQLite solves the issue you're talking
here. From the upper level (us) they solve this the same way (locks,
commits, etc) and they are both widely used.

>    I would say that if you're willing to try, the next step should be to
>    point out which source files contain database calls.
>    Do you have, or could you write up, a document that lists the source files
>    that call the db.
>    And the unwritten rules that must be followed when making calls to the db.
>    That is the hard part.

Easy. Look at the recent SQLite topic. It do answer your question.

>    The next step after that is easy.  Just have to alter the calls to talk
>    through one of the high rated persistence frameworks... and test.

Ok. I think it worth trying MySQL, too. Though, for other reasons like
speed and end-user choice. I'm willing to review such submissions and
merge it.

Could you please talk in patches, now?

Nicolas Sebrecht

More information about the OfflineIMAP-project mailing list