[
https://issues.apache.org/jira/browse/SOLR-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835075#action_12835075
]
Hoss Man commented on SOLR-1687:
--------------------------------
Hmmm... QParser.getSort is where the current sort/start/rows param parsing
happens right now, but looking at it makes me realize there's some local params
semantics to consider with something like this.
Currently, QParser.getSort won't consult the global params if any of
sort/start/rows are specified as a local param (or if the caller explicitly
says useGlobalParams=false, but there doesn't seem to be a code path where that
happens)
but what should happen in these situations...
{code}
#1) q={!lucene rows.max=9999999999 rows=9999}foo&rows.max=100
#2) q={!lucene rows.max=100 v=$qq}&qq=foo&rows=9999999&rows.max=99999999999
{code}
situation #1 could come up if a greedy client attempted to ask for too many
rows, and the admin has a configured invariant of rows.max=100 -- in which case
we'd want the global rows.max param to superseded the local rows param. But
situation #2 is equally possible where the q param is an invariant set by the
admin, and the other params come from a greedy client.
The best situation i can think of off the top of my head would be to ignore
local param values for start.max and rows.max, and look for them as global
params even if false==useGlobalParams. That takes care of situation #1, and
makes situation #2 easy to deal with by also adding rows.max=100 as an
invariant outside of the local params.
Anyone see any holes in that?
> add param for limiting start and rows params
> --------------------------------------------
>
> Key: SOLR-1687
> URL: https://issues.apache.org/jira/browse/SOLR-1687
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
>
> conventional wisdom is that it doesn't make sense to paginate with "huge"
> pages, or to drill down "deep" into high numbered pages -- features like
> faceting tend to be a better UI experience, and less intensive on solr.
> At the moment, Sold adminstrators can use "invariant" params to hardcode the
> "rows" param to something reasonable, but unless they only want to allow
> users to look at page one, the can't do much to lock down the "start" param
> expect inforce these rules in the client code
> we should add new params that set an upper bound on both of these, which can
> then be specified as default/invarient params in solrconfig.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
