On Mon, Jun 23, 2014 at 2:12 AM, Antonia Horincar <[email protected]> wrote: > How about the case when the admin switches from one search backend to > another, shouldn’t the appropriate index be populated with all existing > resources in BH? This is mainly why I was thinking I need to implement my own > admin commands.
This can also be done using bhsearch admin command. When admin decides to switch search backends, he needs to modify search_backend setting in trac.ini and run trac-admin bhsearch upgrade. This looks like a reasonable workflow to me. We could extend the environment_needs_upgrade method in BlodhoundSearchApi to monitor for backend change and request an environment upgrade when it does, but I do not think that this is a priority. > I am currently working on displaying the retrieved Solr results in the > interface. The results are currently shown in the interface, but I am working > on applying highlighting and faceting. > > Also, I have a question regarding the meta keyword parsers. How are the > DocTypeMetaKeywordParser and the other keyword parsers from > bhsearch.query_parser used? MetaKeywordParsers are just match_and_replace rules for words beginning with a $. They are used in MetaKeywordPlugin which could be summarized as: find all words that begin with a $ using a regexp match, pass the word to MetaKeywordParsers, if any of them knows the keyword it will return some text, which you use to replace the keyword string in the original query. > I understood in general what the DefaultQueryParser does, however I’m not > sure I get how parser plugins are used in Whoosh. I would like to understand > the query_parser module better because I used the DefaultQueryParser for > parsing the query. I’m not sure if this is a good idea because basically it > uses Whoosh for parsing the query, but it was easier for the moment. Should I > try to implement my own query parser for Solr? If I understand correctly, solrs expects the query as a string, which it then parses internally. If it is not too hard to reconstruct the query from whoosh, I would use the existing query parser, so you can reuse the existing security processing and meta keyword parsing. If you want to know more about how whoosh parses queries, here is a short description. Whoosh parses queries with a bunch of match and filter plugins. Match plugins try to match the word to a predefined regular expression and emit a node class upon match. Filters then modify the generated list of nodes to group nodes based on operator priority, manage terms without defined fields etc. MetaKeywordPlugin is both a matcher and a filter. It matches all words starting with a $ and passes them to MetaKeywordParsers. If a MetaKeywordParsers understands a keyword, it expands it into a new string ($ticket -> type:ticket), which is again parsed by whoosh. Parsed representation of the expanded meta keyword is stored inside a MetaKeywordNode. In the filter phase, MetaKeywordPlugin "flattens" the meta keywords (replaces meta keyword nodes with the parsed representation of the expanded text. Anze [1] https://github.com/apache/bloodhound/blob/trunk/bloodhound_search/bhsearch/api.py#L402
