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