Senario
Hit one issue in production: when we query solr, the parameter rows is too small.
We need fix this problem ASAP.
One possible solution is to fix the code and make a new deployment.
Another possible solution is to change the data so the one we want to return to client listed at first.
The solution that we used is to change solrconfix xml(only we uses the solr server) to always get 100 rows, ignore rows client passes.
https://wiki.apache.org/solr/SearchHandler
-- invariants - provides param values that will be used in spite of any values provided at request time. They are a way of letting the Solr maintainer lock down the options available to Solr clients. Any params values specified here are used regardless of what values may be specified in either the query, the "defaults", or the "appends" params.
Hit one issue in production: when we query solr, the parameter rows is too small.
We need fix this problem ASAP.
One possible solution is to fix the code and make a new deployment.
Another possible solution is to change the data so the one we want to return to client listed at first.
The solution that we used is to change solrconfix xml(only we uses the solr server) to always get 100 rows, ignore rows client passes.
https://wiki.apache.org/solr/SearchHandler
-- invariants - provides param values that will be used in spite of any values provided at request time. They are a way of letting the Solr maintainer lock down the options available to Solr clients. Any params values specified here are used regardless of what values may be specified in either the query, the "defaults", or the "appends" params.
<requestHandler name="/select" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
<int name="rows">10</int>
</lst>
<lst name="invariants">
<int name="rows">100</int>
</lst>
</requestHandler>
Later we fixed the code and design issue, and removed the invariants in solrconfig.xml.