Re: [Evolution-hackers] EBookBackendSqliteDB comments
- From: Chenthill <pchenthill gmail com>
- To: sean finney <seanius seanius net>
- Cc: Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] EBookBackendSqliteDB comments
- Date: Thu, 05 May 2011 11:20:45 +0530
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
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]