[CalendarServer-dev] Fixing #207
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.
* 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