Hi Chris, I think you are leading me to the right direction.
I'm not sure how that would have worked in Solr 4.5, ... unless > perhaps your definition of a "date" field was different in the schema's > you used in 4.5, and did not involve a Trie based date field (the very > old legacy date format ields used a simple String based encoding that > might have worked) You are right. In Solr 4.5 we had: <field name="valid_date" type="pdate" indexed="true" stored="false" /> <fieldType name="pdate" class="solr.DateField" sortMissingLast="true" omitNorms="true"/> I will need some time to digest all information you provided. I will let you know. Thank you very much. Victor On Tue, Apr 25, 2017 at 2:45 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > : The correct way for a plugin to do the sort of thing you are trying to do > : would be to use an instance of SolrQueryParser -- see for example the > code > : in LuceneQParser and how it uses SolrQueryParser ... you'll most likeley > : just want to use LuceneQParser directly in your plugin to simplify > things. > > ...or depending on how low level you want to deal with things, consider > using IndexSchema.getField(...).getFieldType().getRangeQuery(null, ...) to > build your range Query object directly from the low/high end points > provided as input instead of needing to build a string just to parse it > again. > > > -Hoss > http://www.lucidworks.com/ >
