Re: [Evolution-hackers] EBookBackendSqliteDB comments

[Chenthill <pchenthill gmail com>]

On Thu, 2011-05-05 at 14:49 +0200, sean finney wrote:
> 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.
This is far better. Would get it done this way.

- Chenthill.
> 
> > > 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