[Kde-pim] Mix of config and cache data

[Kevin Krammer]

On Monday, 2012-04-23, Martin (KDE) wrote:
> Am 23.04.2012 14:44, schrieb Kevin Krammer:
> 
> [snip]
> 
> >> I like the idea to use a DB for storing cache data. May be it is a good
> >> idea to store config data in a DB as well, but I an not sure that it is
> >> a good idea to store configuration and cache data in the same DB (IMHO
> >> it is a bad idea).
> > 
> > What is the configuration data that is stored in the DB?
> 
> I don't know. But in the named thread from December last year a
> developer made clear that deleting the akonadi DB is a really bad idea.
> If this DB stores cached data only this should not be any problem. So it
> is my guess that there are config data stored in the DB as well.

Ah, a misunderstanding then.
It is a bad idea mostly because there is potentially data that is not saved to 
the actual storage location yet, e.g. changes to items that reside on a 
server.

Additional to that there could be meta data attached to items that is not 
storable at the actual storage location, e.g. read/unread status for mails in 
mbox files.

The only configuration-like data that is also in the DB is folder specific 
settings, e.g. (I think) folder expiration time and action.

> >> I am not sure that I understand the SizeThreshold parameter. Is this the
> >> amount of data (MBytes or data sets) that are stored in the cache DB?
> >> What are the consequences if I set this value to 0 or a even higher
> >> value than the default.
> > 
> > Its unit is bytes, i.e. size of payload parts (which in turn depend on
> > the data type, e.g. a full contact or headers of an email or full email,
> > etc).
> > 
> > All content that is above the threshold is cached in files, all content
> > up to the threshold is cached in the DB.
> 
> OK, thanks for the explanation. Where are the cache files located? Can I
> exclude them from backup/sync?

$XDG_DATA_HOME/akonadi/file_db_data

with $XDG_DATA_HOME being specified to have $HOME/.local/share as its default 
if not set.

I don't know how Akonadi server deals with such files not present but assuming 
that it will just fetch the data again you might be able to not backup those 
files if you can make sure all pending changes have been written back to their 
respective storage location.

Cheers,
Kevin

> Regards
> Martin
> 
> > Cheers,
> > Kevin
> > 
> >> Martin
> >> 
> >>> Please keep in mind that content that is not uploaded to the respective
> >>> storage location yet will be lost if you only backup the DB in such
> >>> cases.
> >>> 
> >>> Cheers,
> >>> Kevin
> >>> 
> >>> P.S.: if $XDG_CONFIG_HOME is not set the specified default is
> >>> $HOME/.config
> 
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120423/af6d1ba5/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/