Re: [Evolution-hackers] Contacts database modifications history

[Patrick Ohly <patrick ohly gmx de>]

On Tue, 2014-04-15 at 13:16 +0000, Potrola, MateuszX wrote:
> In my project I’m using EDS as backend for storing contacts
> synchronized using Syncevolution.
>
> I would like to have ability to receive some kind of notifications (or
> store information in some additional database) about modifications
> made to contacts database during synchronization.
>
> What I mean by modification is information about contact id and list
> of contact’s fields that were modified (creation and removal of
> contact can be special case - list of all contact’s fields that are
> set will be returned).
>
> I know that current implementation of EBookView allows for something
> similar - it allows for detecting newly created, removed or modified
> contacts, but unfortunately it doesn’t provide details of
> modification.

For those who were around at the time, there used to be a similar
feature which recorded the UIDs of added, modified and removed contacts.
It did not record individual changes and was not as configurable as
Mateusz wants it to be now.

I was on of those who argued in favor of removing that API because it
had several design flaws:
     1. Reading changes automatically destroyed the recorded changes, so
        one could not use it to just check whether something had been
        modified.
     2. Changes were recorded for each client asking for it. EDS had no
        way of knowing whether the client was still interested in the
        changes and no garbage collection, so it ended up recording
        changes in perpetuity if the client was not given a chance (or
        forgot) to unregister.

I wouldn't mind seeing a change tracking API getting re-added to EDS if
these design flaws get addressed. If there is not enough interest in
that, then a solution were such a feature can be added to EDS by a
system integrator via plugins or conditional compilation would also
satisfy Mateusz needs.

> I came up with two slightly different approaches how this could be
> achieved.
>
> 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.

> Cons:
>
> -       Quite complex implementation, especially if some API needs to
> be exposed by EBookClient

Perhaps the API for reading the changes could be limited to direct read
access, potentially outside of the core libebook?

> Second solution is to extend current implementation of EBookView and
> add new signals like: contacts_added, contacts_modified,
> contacts_removed which will be providing ids and list of modified
> fields. Also new function for setting fields of interest will need to
> be added. Again in the address book backend implementation of logic
> for calculating modifications and emitting this signals will have to
> be added (it can be added to current file backend implementation or
> like in previous idea, new backend can be created based on file
> backend).

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.

> Pros:
>
> -       Way of storing modifications information is up to the client
> application,
>
> -       In our case we would like to know what modifications were made
> during synchronization, EDS is not aware of which modification of
> contacts are part of which synchronization, but client application has
> this knowledge.
>
> Cons:
>
> -       We may end up with out of sync data in case if some signals
> will be not emitted.

I see that as the most important reason why I would prefer the more
integrated approach.

Bye, Patrick