Re: [Evolution-hackers] EBookSqlite support for EWS

[Tristan Van Berkom <tristan upstairslabs com>]

On Fri, 2014-08-22 at 17:46 -0500, David Woodhouse wrote:
> On Fri, 2014-08-22 at 17:04 -0500, David Woodhouse wrote:
> > ¹ Seriously, it *was* an accident. I thought I needed to port to
> >   EBookSqlite to make cursors work, which I need for Yuuma's PKCS#11
> >   module. But EBookBackendSqliteDB can do cursors anyway, so I didn't
> >   need to do the conversion. Not that it's not worthwhile anyway...
>
> Hm, actually I think maybe it *is* necessary. Sure, we have 
> e_book_backend_sqlitedb_cursor_new() but we can't make an
> EDataBookCursor out of that. Commit a8e5f5c0 ported
> EDataBookCursorSqlite over to be based on EBookSqlite and now it doesn't
> work for EBookBackendSqliteDB any more.
>
> But that's OK; I've done the port to EBookSqlite now anyway. And as an
> added bonus, as it migrates to the new database format I can add new
> summary fields. With the new PKCS#11 module we're *really* going to want
> e_book_query_field_exists(E_CONTACT_X509_CERT) to be fast.
>
> Unfortunately, we only support boolean and string fields in the summary;
> we can't just add E_CONTACT_X509_CERT to the list of summary fields.
>
> Although actually, all I *wanted* was a boolean. I didn't really want
> the whole of the cert data to be duplicated in the summary; I only
> wanted a boolean indication that the cert was *present*...
>
> Tristan, any ideas on how best to handle this?

Hi David,
    Unfortunately I did not take into account the possibility of
speeding up e_book_query_field_exists() queries without speeding up
other queries on the same EContactField when designing the
ESourceBackendSummarySetup extension API.

That said, there are two clear paths to achieving what you want.
One way is to add a synthetic boolean EContactField (described in more
detail below) and the other would be to extend EBookSqlite and
ESourceBackendSummarySetup to allow for speeding up
e_book_query_field_exists() tests without adding the entire string to
the summary.

While the latter would benefit other possible use cases, I doubt that
there are enough use cases to justify the work it would take, so I would
suggest the former 'easy way out'.


Adding a synthetic boolean EContactField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some contact fields are synthetic fields which are basically resolved on
demand whenever an EContact is asked for the value of the given field.

Some relevant examples of these are the E_CONTACT_NAME_OR_ORG and
E_CONTACT_CATEGORIES fields as they are easy enough to follow in
e-contact.c

If you were to define a new synthetic boolean field named
E_CONTACT_HAS_X509_CERT, then you would just need to add a case to
e_contact_get() which returns TRUE or FALSE depending on the presence of
the certificate in the vcard, and you would have a usable EContactField
to use for your addressbook summary index.

This would of course not speed up:
     e_book_query_field_exists (E_CONTACT_X509_CERT)

but would allow you to add E_CONTACT_HAS_X509_CERT to your summary as an
indexed boolean field.


Also, while I'm here, your patch which modifies the
EBSQL_LOCK_OR_RETURN() macro looks fine and correct to me, you also
have my blessing on your patch which adds the E_BOOK_SQL_SYNC_DATA_KEY,
The only reason I did not add that one is because I did not see it being
used in the backends I looked at.


I hope this mail was helpful to you and I'm happy to see EBookSqlite
get some more mileage :)

Best,
    -Tristan