Tinkering with the search query

Sometimes the search query isn't enough. Sometimes the administrator needs to add a few restrictive clauses or maybe inject some SQL to tweak the results. Content Server is very careful about tidying up search strings which means that modifying search behaviour is not something that can be done with Idoc. But access points do exist that provide a safe way to unobtrusively alter the query.

A typical search for content will call the GET_SEARCH_RESULTS service which accepts a search clause in the variable QueryText. The clause is a unique assortment of commands known as the "Universal Query Language" designed for maximum compatibility with various databases and search engines (most of which are probably now obsolete) but nonetheless requires "massaging" by the system before it is rendered in a usable format. It also acts as a safety guard again malicious attacks, rejecting anything that is not a recognised search query. Try to construct or append any exotic search clauses and they will be rejected before the search gets executed.

Altering the QueryText needs to be done after Idoc processing. This means it will require a Java filter in a custom component. The first useful filter is prepareQueryText. Extra clauses can be added to the QueryText and the system will continue to parse, validate and reformat the clause as though the user requested it themselves. In fact, any changes to the QueryText here will be returned to the user.

If you don't want the user to know that the query was modified, try the fixUpAndValidateQuery filter. By this point the clause has been cloned in preparation for conversion to a database-friendly format - the original QueryText will be restored after the search execution. Any query alteration must still be in the Content Server's query format to satisfy parsing.

If you don't want to be limited by clause conventions and you just want to write a pure query alteration in SQL, then use the postFixUpAndValidateQuery filter. It's the last spot you should modify the query. I don't think it's included in older Stellent versions though, only UCM 10g and up.

A note about debugging - after the prepareQueryText filter the query gets compared to older queries for cached search results. This may mean the filters that follow won't be triggered again because their computations would already have been part of the cached search.

So now that I have explained where to do it - don't do it! Tinkering with the query could expose your database to attack or corruption. Never inject directly from an Idoc variable, form submission or URL without screening and cleaning.

If you don't want to write a Java component just to modify the search query, try adding SearchQueryFormat=DATABASE to your URL. This bypasses the query conversion and allows SQL to be passed in. You'll need to know the format of your particular database. This approach gets mentioned here.