Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-09 Thread Chenthill
On Fri, 2011-05-06 at 10:01 +0200, sean finney wrote: Hi Milan, On Fri, May 06, 2011 at 08:56:10AM +0200, Milan Crha wrote: 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

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-09 Thread Chenthill
On Fri, 2011-05-06 at 08:56 +0200, Milan Crha wrote: (Please do not reply to me, reply to the list, I read the list and I prefer to Ctrl+L while your message avoids this feature for me. Thanks for your understanding.) On Thu, 2011-05-05 at 12:23 +0530, Chenthill wrote: you scary me. Could

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-06 Thread sean finney
Hi Milan, On Fri, May 06, 2011 at 08:56:10AM +0200, Milan Crha wrote: 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

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread Chenthill
On Wed, 2011-05-04 at 13:04 +0200, sean finney wrote: Hi Everyone, I spoke with chen on IRC this morning and got hinted at a preliminary implementation of EBookBackendSqliteDB sitting in -ews. Since there are some benefits of something something like this make it's way to a common place

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread Chenthill
On Thu, 2011-05-05 at 11:20 +0530, Chenthill wrote: * not sure of this one: given there may be multithreaded access to the db, do we need to provide any external big locks on reads/writes? maybe Though sqlite has it, i have read in the FAQ that it recommends applications not to

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread sean finney
Hi! On Thu, May 05, 2011 at 11:20:45AM +0530, Chenthill wrote: * No backend _get_contact/_get_contacts equivalent. Should be easily implemented. _get_vcard_string == _get_contact, i have not added an API return EContact to let the callers decide whether they want to parse the string

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread Milan Crha
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

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread Chenthill
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

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread sean finney
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