Re: [Evolution-hackers] EBookBackendSqliteDB comments

[Chenthill <pchenthill gmail com>]

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 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?
> > Well, I have not started on the meta-data storage yet :) Just have a
> > table for it. There is no specific design for it. 
> 
> 	Hi,
> my above question wasn't only about meta-data, it was a general question
> "what are you doing and how are you doing that". Without that answered
> it's just confusing. I will appreciate something like "we have now these
> options, storing these values... and we will have it changed to this
> which will be doing this and this". I believe you have it somewhere
> done, I only didn't notice where. I'm sorry for that.
> 
> For example, you mentioned once that there should be benefical to use
> only summary columns to be returned for some cases, like autocomplete,
> which doesn't require fully populated contacts. It makes sense from my
> point of view and I will add 
> 
> e_book_client_view_set_restriction_fields_sync (..., const GSList
> *fields_to_fetch, ...)
> 
> which will set list of field names to be fetched only on a view.
Yup that is possible.  This would also need another column mentioning
whether the contact is fully cached or not, will add the same.

> 
> Another thing, I do not understand much why we are talking about XML
> here. Why to combine two approaches when you have one already, the
> database? Though of course, if it's just meant that the key-value pair
> can store (the value part) just anything the caller wants, then yes, I'm
> all fine with it.
Its just about the key-value pairs.

> > > 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 :)
> 
> This is not only about performance, my main concerns are these:
> a) if something fails with db file, user's data are safe
> b) users can take their contacts anytime and import them on another
> machine, in case of hard disk crash, partial backup or anything like
> that
I hope seanus's reply addresses this. For remote address-book's if db is
corrupt, the local keys like 'last-modified' time would be lost, so we
would anyways cache all the data again even if the vcards might be there
to ensure that we are in sync with the server.

I will check the performance impact and if there is no big difference,
will go for storing them as separate files. If there is a considerable
difference, will provide options for both.

> c) folders.db files tend to grow "indefinitely". That's another point
> why I do not like "one file per account".
[i missed say this in the previous reply to seanus, so just adding it
here]
My idea here was to make it configurable, so that all personal
address-books can use one file and a relatively bigger address-book like
GAL can use a separate db file. 
http://git.gnome.org/browse/evolution-ews/tree/src/addressbook/e-book-backend-sqlitedb.h

Rest I hope I have answered in another reply to seanus.

- Chenthill.
> 
> An example: my evo-mapi account has 4 addressbooks (one is GAL). I would
> really prefer to have them separated, not in one large file. Not talking
> about possible (even unlikely) UID clashes between separate
> addressbooks. Will it also mean that each local addressbook will be
> stored in one large db? Please do not do that.
> 
> As I said in the very beginning, I still do not see what you are doing
> and how; it might be a good time to open the code and check that out :)
> 	Bye,
> 	Milan
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers