0

I'm about to add a feature to my project that will allow users to place a Solr query like...

immigration law citations:50

...which would yield legal documents containing 'immigration' AND 'law' AND a citation count greater than 50.

Internally, I can parse out strings like citations:50 and convert them to citations:[50 TO *], but post-processing the query parser is best avoided if possible.

Seems like there ought to be a way in the schema to say, "When people search on this field, always look for the value and find anything greater."

Anything like that or ideas for how to do this elegantly? I hate query postprocessing in my app. Nasty stuff.

mlissner
  • 17,359
  • 18
  • 106
  • 169
  • Are you expecting users to type in `citations:50`? If so, why? – beerbajay May 14 '12 at 07:20
  • Users on my site are (hopefully) quite clever. If you assume that the citation count is a good proxy for the importance of something, you can slough off a good deal of cruft by adding something like citation:10 to your query. – mlissner May 16 '12 at 04:02
  • I meant: why should they have to *write in* `citations:50` in the query instead of writing `50` in a select box (where you then plug in that `50` in your range query)? – beerbajay May 16 '12 at 06:52
  • Ah. Could do that, but there are already too many boxes. Feature doesn't quite warrant one of its own. Just not that universally important. – mlissner May 17 '12 at 02:06

1 Answers1

1

In order not to depend on a particular QueryParser implementation, you could create a custom field type by overriding the getFieldQuery method of the field type you are currently using to return a range query instead of a term query.

See the default implementation for getFieldQuery.

But I still find it a little misleading to have : mean ≥.

jpountz
  • 9,904
  • 1
  • 31
  • 39