[
https://issues.apache.org/jira/browse/SOLR-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870958#comment-13870958
]
Hoss Man commented on SOLR-5627:
--------------------------------
bq. This use case sounds to me exactly like that served by the
SwitchQParserPlugin
SwitchQParserPlugin can only be used in query parser constructs, so it wouldn't
really help in the "rows" type situation mentioned as an example.
bq. My initial thought is that this might be best done as a (custom?)
SearchComponent
I would agree with that ... had SearchComponents existed when i created the
existing defaults/invariants/appends logic i would have done it that way.
bq. You're right, when taking about SearchHandler, But what about other
requestHandlers? for example, update.chain parameter of UpdateHandler.
It's a fair point ... but i'm not sure how I feel about it ... when you start
talking about wanting to enforce rules about requests to Update RequestHandlers
just worrying about the request params that come in s a narrow view -- you
typically need to consider the context of the request (ie: is it a delete? an
add/update? what field=values are in the docs? etc...) A lot of that makes more
sense in custom UpdateProcessors (or using the Scripting UpdateProcessor) ...
your point about the update.chain parameter (which would need to be
constrained/selected before any processors could check the params) seems weird
to me -- the list of update.chains is finite and explicitly configured (not
like rows or start where it's an unbounded number) so i'm not sure i see the
justification of worring about that one specificly -- and as i mentioned, once
a chain is picked, then a processor can be used to constrain the request
params.
or at least ... that's my current thinking, but if you have other examples i'm
open to being persuaded.
As far as the API of something like this (regardless of whether it should live
in a new SerachComponent or not): it seems narrow minded to just say that you
configure a list of explicit values and the client must already know what those
values are and specify them -- it seems like it would make more sense to
support sets of rules for a mapping between some virtualKey=virtualVal param
the clients can send, and what realKey=realValue params will be used as a
result. if you want to confiure virtualKey==realKey and virtualValue=realValue
that's your choice, but i meanwhile might congfigure it so that if the client
specifies "num_results=small" that uses "rows=20"
I also don't think it makes sense to just ignore any params that don't match up
with the constrained list of legal values -- at a minimum there should be an
option to fail with a 400 error.
> Config should contains an "Invariants"-like section, that lets the user the
> choise between a list of options, for a specific param
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-5627
> URL: https://issues.apache.org/jira/browse/SOLR-5627
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Isaac Hebsh
> Priority: Minor
> Labels: config, invariants, solrconfig.xml
> Fix For: 4.7
>
> Attachments: SOLR-5627.patch
>
>
> We want to limit our clients, so they can specify a parameter to request
> handler, but it must be one of some known values.
> When multiple values of a same parameter are defined in {{invariants}}
> section, all of these values are added to the query. This behavior is usefull
> for multivalue params (like {{facet.field}}) but does nothing for params like
> {{rows}}.
> We suggest to add another section, let's call it {{locked-list-values}} (bad
> name...)
> {code:xml}
> <locked-list-values>
> <int name="rows">10</int>
> <int name="rows">50</int>
> <int name="rows">100</int>
> <int name="rows">200</int>
> </locked-list-values>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
