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 calresource.index().search(filter)] ======================================= 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 possible. * 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. /Peter