[Kde-pim] Marketing blocker collection, DEADLINE: 2013-03-10

[Andras Mantia]

Lindsay Mathieson wrote:

> On Thu, 7 Mar 2013 10:59:48 AM Andras Mantia wrote:
>> I guess I need to write the part2 of my blog:
>> 
>> http://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data
>> 
>> As I see the part1 was indeed not that complete regarding what exactly is
>> in  the database and how it acts (although it is valid what I wrote
>> there).
> 
> Um No:
> 
> "To make it clear from the beginning: the Akonadi database *is NOT your
> MAIN data storage.* Even if it gets destroyed, removed, your data is still
> safe."
> 
> This is categorically not true as been abundantly made clear these past
> few weeks and as you your self have been arguing. Deleting the akonadi db
> can destroy you email via errant filters.

No. The fact that it can destroy is independent. The main storage is NOT the 
database. And that still holds. The only time when there is some data (not 
metadata!) that is in the akonadi database, but not stored anywhere else is 
when the main storage (e.g IMAP server) is not reachable, so we couldn't 
upload the data there yet. In technical terms this means that the Akonadi 
item has no remote id.
 Akonadi is designed in a such way that resources *must* store the data from 
akonadi somewhere else as well. If a resource doesn't indicate that it 
stored the data, the request to store will be kept in a queue and the 
resource will be asked again to store the item.
 This is not different at all from KMail1 or other mail applications in this 
sense. You could have mails also in KMail1 that are not stored anywhere, so 
by removing your .kde folder you lost them. 

 Now if you recreated the database, but fail to update the filters, you can 
mess up your data, true. But that does not mean the data is in the database, 
nor that it is the database the problem itself. It is the filtering code 
that starts to move mails to wrong folders.
Same for the (not present anymore afaik) problem with expiring folders. It 
is not Akonadi that expired it. It was KMail doing it so based on wrong 
configuration (that didn't match the reality of the database).
 These are known problems, so care must be taken, but that doesn't change 
the fact that the Akonadi database is not the main data storage.

> Is it any wonder people think its perfectly safe to delete the akonadi db?
> you yourself have been telling them its so.

Sure. Removing the akonadi database in 99% of cases is safe, given that you:
- remove the akonadi config files
- you make the adjustments to KMail and filter configuration after you 
recreated the database

I might have not covered all the cases (and excuse me if I missed 
something), but this is stated in my other writing:

http://userbase.kde.org/KMail/FAQs_Hints_and_Tips#Clean_start_after_a_failed_migration

See point 5. (I need to change point 2 a little to not lose filter config).

Did I contradict myself somewhere?

Andras
_______________________________________________
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/