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. _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers