RQL search bar

The RQL search bar is a visual component, hidden by default, the tiny search input being enough for common use cases.

An autocompletion helper is provided to help you type valid queries, both in terms of syntax and in terms of schema validity.

class cubicweb.web.views.magicsearch.RQLSuggestionsBuilder(req=None, rset=None, **kwargs)

main entry point is build_suggestions() which takes an incomplete RQL query and returns a list of suggestions to complete the query.

This component is enabled by default and is used to provide autocompletion in the RQL search bar. If you don’t want this feature in your application, just unregister it or make it unselectable.

build_suggestions(user_rql)

return a list of suggestions to complete user_rql

Parameters:user_rql – an incomplete RQL query

etypes_suggestion_set()

returns the list of possible entity types to suggest

The default is to return any non-final entity type available in the schema.

Can be overridden for instance if an application decides to restrict this list to a meaningful set of business etypes.

possible_etypes(select, rql_var, prefix='')

return all possible etypes for rql_var

The returned list will always be a subset of meth:etypes_suggestion_set

Parameters:

• select – the annotated select node (rql syntax tree)
• rql_var – the variable name for which we want to know possible types
• prefix – if specified, will only return etypes starting with it

possible_relations(select, rql_var, include_meta=False)

returns a list of couple (rtype, dest_var) for each possible relations with rql_var as subject.

dest_var will be picked among availabel variables if types match, otherwise a new one will be created.

vocabulary(select, rql_var, user_rtype, rtype_incomplete_value)

return acceptable vocabulary for rql_var + user_rtype in select

Vocabulary is either found from schema (Yams) definition or directly from database.

How search is performed

You can use the rql search bar to either type RQL queries, plain text queries or standard shortcuts such as <EntityType> or <EntityType> <attrname> <value>.

Ultimately, all queries are translated to rql since it’s the only language understood on the server (data) side. To transform the user query into RQL, CubicWeb uses the so-called magicsearch component, defined in cubicweb.web.views.magicsearch, which in turn delegates to a number of query preprocessor that are responsible of interpreting the user query and generating corresponding RQL.

The code of the main processor loop is easy to understand:

for proc in self.processors:
    try:
        return proc.process_query(uquery, req)
    except (RQLSyntaxError, BadRQLQuery):
        pass

The idea is simple: for each query processor, try to translate the query. If it fails, try with the next processor, if it succeeds, we’re done and the RQL query will be executed.