I've been looking for this information a long time and found it somewhere on Google groups. I thought it was worth spreading.
I've made the change (Kubuntu Oneiric/KDE 4.8.2/akonadi-backend-sqlite 1.7.2-0ubuntu1~ppa2~oneiric1) and have so far not seen any problems.
Would be great if this could be configured in Akonadi Server Configuration. Better even if this could become the standard for Kubuntu in the future.
Source: https://groups.google.com/forum/#!ms...A/uNC83sXHSFMJ
I've made the change (Kubuntu Oneiric/KDE 4.8.2/akonadi-backend-sqlite 1.7.2-0ubuntu1~ppa2~oneiric1) and have so far not seen any problems.
Would be great if this could be configured in Akonadi Server Configuration. Better even if this could become the standard for Kubuntu in the future.
Techbase says that it isn't recommended, but seeing Gentoo switched to SQLite
as default back with Akonadi 1.4, that statement is outdated IMO. More
evidence for this is the fact that Techbase mentions concurrent access
problems, which should have been resolved in SQLite 3.7 (Write-ahead_Logging
enabled by default).
I have been using Akonadi with SQLite as backend for several months now, and
haven't encountered any issues. On the other hand, I have never compared
performance with MySQL.
SQLite isn't available in the GUI configuration, so you'll have to set it
manually in ~/.config/akonadiserverrc. The database driver is QSQLITE3. here is
my akonadiserverrc :
[%General]
Driver=QSQLITE3
[QSQLITE3]
Name=/home/serafean/.local/share/akonadi/akonadi.db
[Debug]
Tracer=null
The only line you need to change is the Driver line, the rest is filled with
defaults on first run.
I recommend starting with a clean Akonadi configuration. That means removing :
~/.config/akonadi
~/.local/share/akonadi
~/.kde4/share/config/akonadi*
Your local contacts and mail aren't stored in those directories (unless you so
explicitly specified in an agent configuration), so local data is safe.
Akonadi being a cache, removing the database destroys that cache, meaning any
IMAP/GoogleContacts/Facebook ressource will have to resynchronize with its
respective source. This will also happen on a simple database change! The
cache apparently is the database.
--/ /--
TIP : While testing with a new user, kres-migrator created about a dozen local
contact/local mail resources pointing to the same directories, if like me you
don't want to go through them manually, and don't have anything to migrate
from an old kdepim (<4.7), a workaround is disabling kres-migrator by editing
its config : ~/.kde4/share/config/kres-migratorrc :
[Migration]
Enabled=false
as default back with Akonadi 1.4, that statement is outdated IMO. More
evidence for this is the fact that Techbase mentions concurrent access
problems, which should have been resolved in SQLite 3.7 (Write-ahead_Logging
enabled by default).
I have been using Akonadi with SQLite as backend for several months now, and
haven't encountered any issues. On the other hand, I have never compared
performance with MySQL.
SQLite isn't available in the GUI configuration, so you'll have to set it
manually in ~/.config/akonadiserverrc. The database driver is QSQLITE3. here is
my akonadiserverrc :
[%General]
Driver=QSQLITE3
[QSQLITE3]
Name=/home/serafean/.local/share/akonadi/akonadi.db
[Debug]
Tracer=null
The only line you need to change is the Driver line, the rest is filled with
defaults on first run.
I recommend starting with a clean Akonadi configuration. That means removing :
~/.config/akonadi
~/.local/share/akonadi
~/.kde4/share/config/akonadi*
Your local contacts and mail aren't stored in those directories (unless you so
explicitly specified in an agent configuration), so local data is safe.
Akonadi being a cache, removing the database destroys that cache, meaning any
IMAP/GoogleContacts/Facebook ressource will have to resynchronize with its
respective source. This will also happen on a simple database change! The
cache apparently is the database.
--/ /--
TIP : While testing with a new user, kres-migrator created about a dozen local
contact/local mail resources pointing to the same directories, if like me you
don't want to go through them manually, and don't have anything to migrate
from an old kdepim (<4.7), a workaround is disabling kres-migrator by editing
its config : ~/.kde4/share/config/kres-migratorrc :
[Migration]
Enabled=false
Comment