bug: 'str' object is not callable
Sebastian at SSpaeth.de
Fri Aug 26 09:50:05 BST 2011
On Thu, 25 Aug 2011 07:31:15 -0800, Dave Abrahams <dave at boostpro.com> wrote:
> > On Wed, 24 Aug 2011 07:49:23 -0800, Dave Abrahams wrote:
> >> I didn't know there was an sqlite backend. Do I want to use it?
> That sounds like me!
Yep, I would love to remove the EXPERIMENTAL warning in this cycle and
convince people to switch to the sqlite cache by default as I think it
is much better.
> > Having plaintext status caches have advantages, eg in manual parsing and
> > backup, an sqlite db involves way less writes. And as we will write out
> > the full status file for every darn flag change on evey mail, syncs can
> > involve LOTS of disk activity just for that. Switching to the sqlite
> > backend is quite painless if you have a recently synced account, it will
> > import your plaintext status cache (and leave the old one around in case
> > you ever want to go back).
> So, just turn it on? There must be a config variable, right?
You will need the python-sqlite package (or however it is called in your
distro). Yes, it's documented (like all our settings) in the bundled sample
offlineimap.conf and goes into the [Account ..] section:
# OfflineImap caches the state of the synchronisation to e.g. be able to
# determine if a mail has been deleted on one side or added on the
# The default and historical backend is 'plain' which writes out the
# state in plain text files. On Repositories with large numbers of
# mails, the performance might not be optimal, as we write out the
# complete file for each change. Another new backend 'sqlite' is
# available which stores the status in sqlite databases.
# If you switch the backend, you may want to delete the old cache
# directory in ~/.offlineimap/Account-<account>/LocalStatus manually
# once you are sure that things work.
#status_backend = plain
Plaintext is supposed to be more corruption safe, but we've seen a fair
share of status cache corruptions too, so things are not perfect with
the plaintext cache anyway. Feedback is welcome.
> offlineimap --info -u tty -l ~/Library/Logs/offlineimap.log
> hangs basically right away for me, having shown no activity other than
> announcement that it's connecting to imap.gmail.com. There's nothing in
> ~/Library/Logs/offlineimap.log, but that's no surprise: I never see any
> log output until I've quit because offlineimap doesn't flush to the log.
Thanks for testing. It's weird as I can connect to Gmail just fine and
get an output. Back to the drawing board :).
As for the lack of flush: I have a patch that uses the "logging" module
for outputting log information and which would correctly flush debug
log. I don't want to mangle the current code too much and rather switch
to the standard python logging facility.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the OfflineIMAP-project