You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2010/02/18 01:55:33 UTC

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

     [ https://issues.apache.org/jira/browse/SOLR-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-1687:
---------------------------

    Attachment: SOLR-1687.patch

patch with the logic i attempted to describe.  it doesn't contain any Unit Tests yet, but it seems to be working.

the real question is: are there any any holes i haven't plugged in the local/global param handling logic that a greedy client could exploit?

> 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
>         Attachments: SOLR-1687.patch
>
>
> 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.