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