[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#513382: Filesystem backend

On Sunday, 2009-08-09, LEDUQUE Mickaël wrote:
> In fact, in my opinion, the point is to not have the data in ANY big, full
> featured, and space hungry database software.
> I don't understand why something as simple as an address can't just be
> stored in whatever file format you could name. Even csv would work! What
> does a relational database do better when the only kind of search I do is
> based on the contact name?

This is a misunderstanding :)

The data is of course not in the database, it is whereever it stored right 
now, e.g. a vcard file, a LDAP server, remote file, etc.

Akonadi, or rather the Akonadi server, is quite like a proxy, caching data on 
behalf of applications so they don't have to.

The application contacts Akonadi server and e.g. requests a list of all 
"folders" [1] containing contacts.
The server knows which folder corresponds to which data source, e.g. that a 
folder contains the contacts of vcard file.

Once an application requests actual data, e.g. contact, email, whatever, it 
will check whether it has the data cached or whether it has to retrieve it 
from the actual source.

Whether it will then just pass the data on to the application asking for it or 
whether it will also store it (depending on the settings in either DB or file) 
depends on the folder's "Cache policy".

E.g. a cache policy for a local contact file might be to not cache at all, a 
policy for a local maildir might already be "cache headers" (for faster 
listing), the policy for an important IMAP folder could be "cache everything".

Currently these cache policies are mainly determined by the data providers 
[2], but of course the idea it to have applications provide their users 
methods of changing that according to their needs.

In a setup where nothing is cached or where caching happens through indivadual 
cache files, the database will only contain meta and relational data, e.g. how 
the folder structure looks like, which data provider is handling which 
folders, which items are in which folder, MIME types, etc.

Storing such things is what relational databases are really good at.
Of course, different workloads will require different sophistication from 
database implementations, so Akonadi uses Qt's SQL abstraction to be not tied 
to a single one.

Ideally a default setup would use something extremly "light weight", 
e.g.SQLite, however it unfortunately turned out that as this point this is not 
SQLite turned out to have serious problems with multithreading, especially in 
context of transactions, MySQL/Embedded didn't have a backend capable of doing 

While MySQL, as you pointed out, is quite a "heavy" implementation, it is one 
that can provide the required base features and can be run in a way that does 
not need manual database setup.

In the meanwhile some people have provided feedback and respective patches to 
also enable Postgres usage and another group of people are working diligently 
to find ways around SQLite's short commings [3].


[1] in Akonadi called collections
[2] in Akonadi  called resource agents or just resources
[3] AFAIK the current state is that it is no longer deadlocking instantly, 
only after some operations

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: