[jira] Commented: (SOLR-1687) add param for limiting start and rows params

["Hoss Man (JIRA)" <ji...@apache.org>]

    [ 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.