Re: [Evolution-hackers] EBookBackendSqliteDB comments

[Chenthill <pchenthill gmail com>]

On Wed, 2011-05-04 at 13:04 +0200, sean finney wrote:
> Hi Everyone,
> 
> I spoke with chen on IRC this morning and got hinted at a preliminary
> implementation of EBookBackendSqliteDB sitting in -ews.  Since there
> are some benefits of something something like this make it's way to
> a common place that could be used by -mapi as well, I thought I'd do
> a quick feasability review to see what problems there might be.
> 
> Questions/commments/suggestions follow.  Please let me know what you
> think!
> 
>  * No backend _get_contact/_get_contacts equivalent.  Should be
>    easily implemented.
_get_vcard_string ==> _get_contact, i have not added an API return
EContact to let the callers decide whether they want to parse the string
to EContact.

i have not observed any use cases for get_contacts needed by the
backends. _book_backend_sqlitedb_search would server the
_get_contact_list API in the backend and also for querying using a
search query to fetch the contact list.

>  * _add_contact/_remove_contact should be renamed to 
>    _add_contacts/_remove_contacts to be consistant with other backend
>    methods that take lists.
Makes sense as it already acts on multiple contacts.

>  * but also having a _add_contact/_remove_contact that takes just a uid
>    (similar to other backends) would be useful
remove_contacts already takes only uid. I do not know how far
_add_contact with just the uid would be helpful. Which backend would
need it ?

>  * -mapi seems to use one cache per-profile-per-folder, but the sqlitedb
>    backend takes these as calling parameters.  Not really a problem and
>    I think it may be reasons to have one cache db anyway, so this is
>    just more of an observation.

>  * _get/_set/_delete interfaces are needed for cache metadata (last modified,
>    etc).
Am working on it atm.

>  * if folder metadata is going to be free-form, it could be better to have
>    a key->value table ( folder_id_id int, key_name text, value text ) rather
>    than arbitrarily numbered text/binary fields.
I was thinking of allowing the backends to store key value pairs using a
bdata column which could be populated with xml key-value data. Would be
it be good idea ?

>  * not sure of this one: given there may be multithreaded access to the db,
>    do we need to provide any external "big locks" on reads/writes?  maybe
>    the built in sqlite stuff is sufficient.
>  * not sure of this one: beyond the COMMIT statements, should there be
>    something to periodically sync the db beyond the backend "finalize" method?  
afaik it would be taken care of sqlite vfs and commit should be enough.

>    Unsure with commit is sufficient to get consistant on-disk in case of
>    crash, etc.
>  * do we need a set_populated/is_populated equivalent?  or maybe that could
>    be solved in the cases it's needed wtih metadata.
I think I added it and removed later thinking it might be redundant with
sync_data column, but re-thinking now am clear both are independent.
Will get that added...

>  * do we need a set_time/get_time equivalent?  or maybe that could
>    be solved in the cases it's needed wtih metadata.
There is a sync_data column which can be used for the same with either
last_modified date or sequence numbers or some synchronization text.

> 
> @chen: I don't know how active you plan to be on this, but if you're looking
> to offload any work, I can pick up anything that results from the above if
> you like.  Just let me know!
The work is almost over, but will let you know once i finish the testing
and you can directly make changes if you require anything more there :)

- Chenthill.
> 
> 
> 	Sean
>