Re: [Evolution-hackers] EBookBackendSqliteDB comments

[Milan Crha <mcrha redhat com>]

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?

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

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.

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?
	Bye,
	Milan

P.S.: I confess I didn't open your code, I only read this thread.