Re: [Evolution-hackers] EBookBackendSqliteDB comments

[Milan Crha <mcrha redhat com>]

(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.

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.

> > 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
c) folders.db files tend to grow "indefinitely". That's another point
why I do not like "one file per account".

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