[
https://issues.apache.org/jira/browse/SOLR-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175070#comment-17175070
]
Cassandra Targett edited comment on SOLR-13528 at 8/10/20, 9:34 PM:
--------------------------------------------------------------------
The Ref Guide docs in this commit were throwing some errors in the build (not
failing it though) about inconsistent heading levels, which I only noticed
because I was working on fixing our new Jenkins builds.
I'm about to make a commit to fix that, but I noticed that the headings in
question are all parameters users can configure. That's not generally how we
structure parameters, especially when there is not a lot of text for each one
(we have a couple examples of this being done, but I will someday get around to
changing those to be like the majority of the parameters throughout the Guide,
like in
https://lucene.apache.org/solr/guide/8_6/detecting-languages-during-indexing.html#langid-parameters).
I'm also uncomfortable with how the example parameters are shown (as separate
source blocks). I think it might be simpler and more instructive for readers to
restructure this a bit, to show a full configuration of the
{{SolrRequestFilter}}, with all the parameters in a single block. Users can
then copy/paste it more easily and will be less likely to miss a parameter. As
it stands, I have to do a bit of mental gymnastics to figure out where this
needs to go (full path to the file) and what it should look like.
I'm fine doing this myself, I just wanted to let you know what I am going to do
and why. Of course, if you'd like to do it, I'll be happy to let you.
was (Author: ctargett):
The Ref Guide docs in this commit were throwing some errors in the build (not
failing it though) about inconsistent heading levels, which I only noticed
because I was working on fixing our new Jenkins builds.
I'm about to make a commit to fix that, but I noticed that the headings in
question are all parameters users can configure. That's not generally how we
structure parameters, especially when there is not a lot of text for each one
(we have a couple examples of this being done, but I will someday get around to
changing those to be like the majority of the parameters throughout the Guide,
like in
https://lucene.apache.org/solr/guide/8_6/detecting-languages-during-indexing.html#langid-parameters).
I'm also uncomfortable with how the example parameters are shown (as separate
source blocks). I think it might be simpler and more instructive for readers to
restructure this a bit, to show a full configuration of the
{{SolrRequestFilter}}, with all the parameters in a single block. Users can
then copy/paste it more easily and will be less likely to miss a parameter.
I'm fine doing this myself, I just wanted to let you know what I am going to do
and why. Of course, if you'd like to do it, I'll be happy to let you.
> Rate limiting in Solr
> ---------------------
>
> Key: SOLR-13528
> URL: https://issues.apache.org/jira/browse/SOLR-13528
> Project: Solr
> Issue Type: New Feature
> Reporter: Anshum Gupta
> Assignee: Atri Sharma
> Priority: Major
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> In relation to SOLR-13527, Solr also needs a way to throttle update and
> search requests based on usage metrics. This is the umbrella JIRA for both
> update and search rate limiting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
