Bug 237127

Hej Adrijan,

your use case is quite a kind of a cornercase...
The problem you are facing is, that Akonadi uses a cache to provide fast
access to all data from the resources it is aware of.

If you initially start KAddressBook on partition 1, Akonadi from partition 1 parses
all contacts from $HOME/.local/share/contacts and stores them in the cache.
Changes in KAddressBook are written back to the cache and the file system.
Now if you start KAddressBook initially in partition 2, Akonadi from partition 2 also
loads the contacts from file system and stores them in its cache (note that
this is a different cache then the one on partition 1!). Changes to KAddressBook
are again written back to the cache and the file system.

Now if you start KAddressBook on partition 1 again, the vCards from the contact/
directory are not read in again, because they are already cached - under the assumption
that nobody changed the files while Akonadi has not been running (which is a wrong
assumption in your special case), so Akonadi doesn't know about changes you did from KAddressBook
on partition 2. Changing data in KAddressBook will overwrite the data on the file system now.

So one solution would be to always reload the cache when starting Akonadi, however that
could be a serious performance problem... For this reason I'm not sure how to solve this
problem... I'll talk with the other developers

Ciao,
Tobias

Thanks for the prompt response.

First, my special case may be particular but it reveals one issue which is a problem of sharing a resource in KAB/akonadi. What if I decide to share the resource on the LAN or even with a smartphone. In the past I did have my contacts shared on lan and had no problem because there was a "save" button on KAB and also when opened it was reading the actual std.vcf file.

Now if we also add cached contacts (which the user has no control upon) into the equation obviously the matter gets complicated.

I am no database expert but I imagine that some other brilliant minds have found solutions for such issues on bigger databases.

IMHO the problem starts when KAB overwrites the vcf file without notifying you that the file was changed (by another app or KAB instance) since last time you viewed it. I think this action in itself goes against any logical database management principles.

Lastly, I have to ask you this question: If you say that my case is so singular how is one supposed to share resources in the new Kontact? Am I using it the wrong way? Or will I encounter the same problem if I decided to share a contact database,for example, on an LDAP server?

I am asking this because I was really in the process of looking for a sharing solution as we may be moving to smartphones and I would logically like to have access to the same contacts database from home, work, and on the road.

Hej,

well, you can't really compare our setup with a plain database setup.
With a plain database setup, all data are stored in the db repository on
the file system, so when you shut down one RDBM instance and start another
instance on the same db repository, it will have all data available.

In our case, the data is located in two places, on the file system and inside
the cache, and you 'switch' only half of the data by using a shared file system
but different caches...

Actually we introduced Akonadi to avoid exactly this problem... the Akonadi server
(and its cache) shall be the single instance where all accesses to the data go through.
The network based resource has code to reload the contacts on every startup, so it
always gets the most current version, just the 'Personal Contacts' resource has not.
But as I told you, I'll talk with the other developers about this issue...

Ciao,
Tobias

SVN commit 1127307 by tokoe:

Always synchronize the cache with the filesystem on
startup to not miss any changes to the filesystem that
has been done while Akonadi is not running

BUG: 237127


 M  +4 -0      contactsresource.cpp  
 M  +3 -0      contactsresource.kcfg  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1127307

I think this solves only part of the problem.

What if I access the filesystem simultaneously with 2 apps. Or if the directory is shared and my wife accesses it with her laptop.

I would suggest looking into:
1. Manual button in GUI to synchronise with filesystem.

2. If the user opens a contact for editing it should be loaded from the filesystem (synchronised). This should be done only for that specific contact to reduce traffic. This would ensure that one user is not editing what another user already did.

3. Currently, if the user edits a contact and closes the window the vcf file gets overwritten regardless if it matched or not what was in Akonadi's cache.
Akonadi should notify the user if the vcf file it overwrites is not the same as was in the cache. (just like Kate does when you open a system file and the system modifies it after you opened it).

Just an observation:

It appears to me that the "personal contacts" type of resource was only intended to be used in a unique instance of Akonadi. See the warning file in the ./local/contacts folder. If it is indeed intended for a single user single instance then this bug should be addressed in a different manner.
Akonadi should place some sort of lock on the directory, so that no other Akonadi instance or another app can use it. IDK if this is possible.
But I know that you can't just rely on a text file in a folder to tell users not to use that kind of resource in a multi-user/instance environment.

If this can't be done then I would just treat all resources the same way whether they are shared (on the network) or not. This will also eliminate the current confusion when adding address-books.