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? Ah! 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 possible. SQLite turned out to have serious problems with multithreading, especially in context of transactions, MySQL/Embedded didn't have a backend capable of doing transactions. 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]. Cheers, Kevin [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.