Banshee's search code is getting revamped. Before getting into the technical discussion, I want to note that
simple queries that you can perform in stable today will most of the time produce the same results in trunk. In trunk, the default operator in user-queries is AND, so a query
dave matthews is parsed as
dave AND mathews. Filtering is done in real-time as you type, and mal-formed queries are handled gracefully. You can also specify fields (by:dave, album:"under the table", rating=4).
Trunk is well
organized into assemblies that break along logical boundaries. One of these assemblies is called
Hyena, and contains reusable data-oriented classes. I want to highlight one namespace in it that has come a long way in the last few weeks.
Hyena.Data.Query
The fundamental data structure in Hyena.Data.Query is the QueryNode tree, made up of QueryTermNodes (literal values, field queries) and QueryListNodes (and, or, not).
We have two parsers, UserQueryParser and XmlQueryParser, as well as methods to take a tree and produce user or XML queries. This means we can go from a user query to XML and back, or vice-versa. Given a list of queryable fields and their mapping to Banshee's database (a QueryFieldSet), we can also take a tree and produce SQL for actually carrying out the search. You can see all this in action if you run trunk from a terminal:
All this work makes searching much faster (straight against the database), unifies our search infrastructure, and makes it trivial to implement features like dragging a smart playlist onto the search entry and turning a search into a smart playlist.
Both our
user-query language and XML are extremely close to the
XESAM spec, and we want to be compliant. We're
working with the XESAM team to make sure it meets our needs.