lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <>
Subject [jira] [Commented] (SOLR-4208) Refactor edismax query parser
Date Wed, 26 Dec 2012 22:56:12 GMT


Tomás Fernández Löbbe commented on SOLR-4208:

bq. Could you make the patch such that it's not an entire file replacement so we can more
easily see what's changed exactly?
I think moving the parser to a different file is a good part of the refactor. I'm attaching
the file "qParserDiff.txt" to show how the parser changed with the refactor, but I'm keeping
it separately on SOLR-4208.patch.

bq. Perhaps rather (or in conjunction with) making the parser easier/cleaner to "extends",
we could make it open to Solr-style "plugins", where the edismax parser itself is still used
directly, but various overrides/extensions can be plugged in (and perhaps made query-time
changeable[!] by name lookup Solr-plugin-style; see HighlightComponent for example)

This is a good idea. When I started to work on my use case I initially thought on having something
like the UpdateRequestProcessorChain at query time that would end with the EdismaxQParser
itself (maybe a QParser that would add this component chain and use the EdismaxQParser as
part of it), but that wouldn't give me enough points to extend, because the "parse()" method
was going to be executed by the EdismaxQParser and there was no way of modifying its behavior.
Maybe there is another way of add a "plugin style" that allows more customization?

In the meantime I'm attaching a new patch with some more minor changes and some tests

> Refactor edismax query parser
> -----------------------------
>                 Key: SOLR-4208
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Tomás Fernández Löbbe
>            Priority: Minor
>             Fix For: 4.1, 5.0
>         Attachments: SOLR-4208.patch
> With successive changes, the edismax query parser has become more complex. It would be
nice to refactor it to reduce code complexity, also to allow better extension and code reuse.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message