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