Today my team mate and I worked on adding filters to the queries we already have using the prototype version of the filtering system he built earlier.
A “filter” is similar to our previous concept of a “field” for the query but more powerful. A field allowed the user to specify a parameter which was then inserted into our pre-built queries which were hard coded on the Get API. We called the queries we built “presets” because that made more sense. A query was really a preset combined with a user-specified parameter.
Filters, instead of taking a user specified value and inserting it into a specific part of the query, dynamically built a “match” part of a MongoDB aggregation query. The matches are pieces of the query which usually go on the very front of it to restrict what’s returned. It’s the equivalent of the “WHERE” clause of an SQL query. The filter system allows the user to build none of these matches, just one match, or many matches, and the aggregation framework of MongoDB just pipes the results through them. The user can now use any field and value for that field they want. Our job now is to help the system create useful results, protecting it from invalid filtering.
This meant that instead of creating more queries today or adding more to the existing queries, my work was to help my team mate by changing the queries to enable the use of MongoDB’s aggregation framework for each of them, and to begin coding up the various error messages that would be thrown for invalid filtering. I feel this is worth my time, since a robust querying system, including filtering, is something that Engineering.com has on their wishlist according to the feedback we got when we demoed what we had on Thursday.
Matt@Seneca 