-
Notifications
You must be signed in to change notification settings - Fork 132
Search query interpretation
The search string is split in parts by use of the Python shlex module. Unlike splitting on whitespace, shlex understands quoting and so 'hello "foo bar"' would be split into "hello" and "foo bar" unlike a whitespace split which would give 'hello', '"foo', 'bar"' (notice the annoying extra quote characters).
Each part of the query is then analysed and if it looks like an IPv4 or IPv6 address or prefix, it will be treated as one, which means the "equals" operator is used on the prefix column.
Everything else will be treated a text and will thus have a case-insensitive regex match operator applied. Test string will be matched towards the description, comment, order-id or node field of a prefix.
Empty searches from the CLI will give the same result as searching for ''. Since smart_search_* does a regexp search for strings, it will match and return all prefixes.
While in a large ISP setup with thousands of prefixes, it doesn't make much sense to list everything, it does make sense in smaller deployments or if coupled with a VRF selection. If nothing else, it's nice for new users that just running a search returns something.
nipap address list FOO will issue a smart search for "FOO" which in turn will do a regexp match on a bunch of text fields, including the description and comment field. If we want to just do a regexp match in the comment field, the idea is to use the keyword "comment", like so: nipap address list comment FOO. The CLI will match the "comment" argument and put the argument to it in a dict-SQL which will be passed to smart_search in the extra_query argument.
For all these extra arguments, there is the question on how to build the dict-SQL and specifically what search operator to use. For different arguments, the operator should probably be different, for a free text field (like description) an unanchored regexp is suitable while for an integer field, it doesn't fit at all.
Current strategy is to use anchored regexps for things like VRF RT. Novice users will get what they want while more experienced users can use regexp and perform more advanced queries.