lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1687) add param for limiting start and rows params
Date Mon, 22 Feb 2010 21:54:27 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836930#action_12836930
] 

Hoss Man commented on SOLR-1687:
--------------------------------

bq. Traditionally, this type of stuff is delegated to the front-end clients to restrict.

True, but my suggestion wasn't so much along the lines of "end users" entering really big
numbers as much as that "client developers" might make mistakes, and this would allow a solr
admin to lock things down in a sane way.

bq. Would it make more sense to add an optional component to check restrictions? The restrictions
could optionally be in the config for the component and thus wouldn't have to be looked up
and parsed for every request.

I like this idea, but given the way local versions of start/rows are treated special wouldn't
we still need special like what i added in the patch to deal with them?  (a generic component
added to the front of the list could check validate a list of global params, but it wouldn't
have anyway of knowing for certain what other params later components might parse with a QParser.

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


Mime
View raw message