[CalendarServer-dev] Fixing #207

Peter Mogensen apm at one.com
Thu Aug 21 01:16:28 PDT 2008

Wilfredo Sánchez Vega wrote:
>   This sounds sane to me.  Cyrus may comment further, since he wrote the 
> first pass at this.

While we're at it. I don't like the way the interface to
class AbstractCalendarIndex (index.py) is wrt. search() and 
searchValid() and the way they're used from report_calquery.py

It seems wrong to first parse the filter to see if an indexed query is 
possible and then parse the filter once more when the actually search is 
done - which then may end up being a bruteforce search anyway, which i 
"secretly" done by search().

The code in report_calquery is:
# See whether the filter is valid for an index only query
index_query_ok = calresource.index().searchValid(filter)

# Get list of children that match the search and have read access
names = [name for name, ignore_uid, ignore_type in 

Both search() and searchValid() parse the filter.

I suggest:
* Renaming AbstractCalendarIndex.search() to indexedSearch()
   and letting it raise an exception if an indexed search is not
* Introducing a AbstractCalendarIndex.bruteforceSearch() which just
   selects all resources from the RESOURCE table (as search() does now)
* Letting report_calquery handle an exception from indexedSearch() and
   call bruteforceSearch() instead.
* Drop searchValid()

This way the filter is only parsed once and only until it is rejected by 
the index and it's more obvious when a bruteforce search is done.


More information about the calendarserver-dev mailing list