Re: [Evolution-hackers] EBookBackendSqliteDB comments

[sean finney <seanius seanius net>]

On Thu, May 05, 2011 at 12:23:01PM +0530, Chenthill wrote:
> > Be sure that parsing bdata is a pain, and always will,
> > especially when you already are in a database world, where are tables
> > and relations between them pretty common and nature.
> This is the reason I was thinking whether it would be good idea to have
> a abstract API to store extended (apart from sync_data, populated
> columns etc.) key-value pairs if the backend needs. This can form the
> xml and store it as bdata. Now the bdata would not be exposed to the
> callers. Is there any other better way to do this ?

Forgive the rusty SQL, but assuming you have a single db with
multiple folders in it, soemthing like:

create table folder_kvdata ( 
	folder_id_id int foreign key references folders(folder_id),
	keyname text,
	keyval text
);

?  With this it would be pretty trivial to fetch single values
as well as enumerate/update/delete all keys/values for a folder.
If the caller needed something more complicated than a single value, 
an xml object or whatever else could be embedded on an as-needed basis.

> > If I recall correctly then "populated" and "last_modified" were also
> > stored as keys in the background, but backend could drop them
> > accidentally, when accessing through keys "directly". It sometimes can
> > be considered a benefit, but it usually isn't. If I have specialized API
> > to access these keys, then I should use it exclusively. I think.
> For the commonly used keys such as the above we would have specialized
> API's and they would be having separate columns on a per-folder basis.

yeah, I think it would be a good idea to claerly break them out from
the "general" k/v pairs, to avoid conflicts and special-casing any code.

> > I recall us chatting about this on IRC or somewhere one day and one
> > point was that the contacts will not be stored in a binary form, but
> > rather as separate files. What Sean wrote earlier sounds like you
> > changed your mind in this point. I do not think it's a good idea, see
> > how often the sqlite folders.db file in camel is broken, and users are
> > adviced to delete it. Will they loose all their contacts in such
> > situation?
> As I already said seanus on irc, I will be evaluating the performance
> between having vcards as files Vs having it in db and then choose the
> one which would be best. So the code for both will be there and we can
> choose between them over after testing. I was also thinking of providing
> it as an option for the backends to choose once i complete the testing..
> So what we discussed stays the same :)

W.r.t. a performance standpoint, I will be testing against a Global
Address List of somewhere around 60k entries, so that should give a
pretty good idea :)

I think Milan also had concerns with regards to "stability/fragility",
with corrupting databases, etc.  But I don't think that the "split out"
option is immune from these types of problems as well (and there may be
even further problems, since we would be home-rolling that solution as
opposed to relying on a well tested API/DB).


	sean