Re: [Evolution-hackers] Contacts database modifications history

[Patrick Ohly <patrick ohly gmx de>]

On Wed, 2014-04-16 at 09:02 +0000, Potrola, MateuszX wrote:
> > > First one is to create new address book backend (which will be
> > > inhering from file backend used by Syncevolution) and add there logic
> > > for calculating modifications when creating/modifying/removing
> > > contacts. These modifications will be stored in additional database,
> > > so some additional functions for handling this will need to be added
> > > to EBookSqlite class.
> > >
> > > Here are some pros and cons that I can see:
> > >
> > > Pros:
> > >
> > > -       If someone don’t want to keep track of modifications history
> > > he can still use file backend
> > >
> > > -       We can be sure that contacts database and modifications
> > > database will be in sync, by using attach function of sqlite
> > > (databases will be separated but transaction for modifying both of
> > > them will be treated as one transaction)
> >
> > Does it have to be a separate sqlite database? You could also use a new table
> > directly in the sqlite datbase also used for the contact data.
> No, it don't need to be separate sqlite database, but I was thinking
> about case where database will be locked because some operation like
> locale update is ongoing, with separate database modifications data
> could be still concurrently accessed.

Doesn't sqlite allow reading while a write is ongoing?

> > Note that the EBookView could also be used as-is by doing the detailed check of
> > what was modified in the receiving process. For new contacts it is very likely that
> > the fields of interest were added, and updating contacts happens rarely enough
> > that the overhead of sending updated data that then completely gets filtered
> > out shouldn't matter.
> I'm not sure about using EBookView as-is and checking what was
> modified in receiving process, because notification will be sent when
> data in contacts database will be already changed, so receiving
> process should first get all contacts from database before starting
> synchronization to be able to do detailed check of what was modified,
> which in case of large number of contacts may unnecessarily increase
> memory consumption, especially as you've said that updates happens
> rarely.

This is a valid concern. Both doing the diff inside the EDS backend (as
part of the write) or in SyncEvolution would work better.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.