Wilfredo Sánchez Vega wrote:
This sounds sane to me. Cyrus may comment further, since he wrote the first pass at this.
Hi, I have a working patch attached at https://trac.calendarserver.org/ticket/207 I haven't found any code style guidelines, so please comment. It can be done better. There were a few things to consider. Like: * I replaces the expression generation functions in calendarquery.py with a class to hold state about the filter expression found during generation. (like: Do we have a timerange with an end date). An alternative would be to traverse expression hierarchy after generation to look for timerange expressions. I think an expression generator object is more fleksible. * I have just returned a tuple (SQL-qualifiers, enddate) from sqlcalendarquery(). This should probably be an object to allow for other future condition, but I couldn't think of any, so it became a simple tuple. * I removed index.searchValid() and replaced index.search with 2 methods: index.indexedSearch(filter) # throwing an IndexedSearchException index.bruteforceSearch() Code using the index for search should now be prepared to handle an IndexedSearchExcetion in case an indexed search is not possible and call bruteforceSearch() them self. I think this is cleaner and it saves the duplication of parsing the filter expression which searchValid() did. * I've been lazy and just removed resources needing expansion from the index and re-adding them with a longer expansion. It would probably be better to just add the missing TIMESPAN entries. ... next version. Please comment, /Peter