Re: [Evolution-hackers] EBookBackendSqliteDB comments

[Chenthill <pchenthill gmail com>]

On Thu, 2011-05-05 at 13:53 +0200, Milan Crha wrote:
> On Thu, 2011-05-05 at 11:20 +0530, Chenthill wrote:
> > >  * 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 ?
> 
> 	Hi,
> you scary me. Could you repeat where is written information about a
> design you chose for this, how it correlates with actual backend
> cache(s) (we do not want to loose functionality here) and maybe why done
> so?
Well, I have not started on the meta-data storage yet :) Just have a
table for it. There is no specific design for it. 

> 
> Like in the above quoted text, is that to replace keys.xml file (it's
> from calendar, I know, but you know what I mean)? Or what do you call
> meta-data? 
In calendar terms, yes.

> I want to be able to store my own keys per account (not per
> item, it's another thing which scary me, one addressbook cache file per
> account, really?) 
Meta-data table is one for an account and folder meta-bata will form the
rows. 

> 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 ?

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

> 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 :)

- Chenthill.
> 	Bye,
> 	Milan
> 
> P.S.: I confess I didn't open your code, I only read this thread.
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers