Re: [Evolution-hackers] Refactoring EWS GAL sqlitedb

[Milan Crha <mcrha redhat com>]

On Wed, 2014-09-03 at 12:04 +0100, David Woodhouse wrote:
> Any other ideas on how to make this happen efficiently?

        Hi,
I also do not follow SQLite's efficiency in the described situation, 
but I would expect that the remove & insert is significantly slower 
than rewrite of certain fields (supposing that the actual rewritten 
value is not longer than the current value, which may move the record 
to a new place). Such massive database rewrites should be also 
finished with a 'vacuum;' call, to help with further reads, disk space 
and so on. Reindexing is also another performance hit in current 
implementation.

Are you able to recognize affected contacts from the binary diff, or 
from anything after the diff is applied? I can imagine that the 
transform from MAPI properties to vCard also takes its time, 
especially with your 200K database, not talking that comparing raw 
vCards can lead to false positives. Being able to recognize the 
changes directly from the OAB file would help the most, from my point 
of view, because then you can update only contact offsets. Maybe 
PidTagLastModified can be used for this?

In any case, I agree that the actual merge of changes with minimal 
impact on the SQLite database is a good idea to have.
        Bye,
        Milan