Notes

Notes on query implementation

• I've run into a weird layering problem with queries: most of the query implementation should live in repository.query. But in order to post the necessary notifications to ItemCollections^?, and to persist the queryString, there needs to be an Item that represents queries. Also, the query implementation needs to subscribe to repository notifications, but it shouldn't use the Chandler notification manager to do this because it violates the layering of the repository. The query engine's notification callback needs to be a method of query (repository layer) to have access to all the data structures that allow it to compute entry / exit of result sets, but it also needs the UUID of the query item to report to item collections (next layer up).

• Generator issues - Python generators are non-restartable/resettable, and there's some weird interactions between KindQuery^? which returns a list and some of my code which uses generators. Incremental / pipeline computation of query results is something that needs some more attention, probably in 0.5.

-- TedLeung - 05 Aug 2004