Mailing List Archive

Eric, based on what you wrote, your proposal makes sense to me.
CC'ing Noble who added this feature originally, I think.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sat, Feb 6, 2021 at 9:56 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> I was reading through the ref guide page on Implicit Request Handlers [1]
> and saw a mention of “paramsets”, which I think is a really powerful
> feature that most people don’t know about.
>
> I then wanted to learn more about paramsets, and tried to find it in the
> ref guide.. I’d learned about this feature in the first place FROM the
> ref guide, so I knew it was there somewhere…
>
> After gripping through source, I found the page Request Parameters API
> [2].
>
> I’m looking for some guidance on if we would want to rewrite the Request
> Parameters API page as the “ParamSets” page, and retire the term Request
> Parameters API.
>
> “Paramsets” shows up 47 times in *.adoc files.
>
> “Request Parameters API” shows up ONLY as part of a link to the page.
>
> I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc,
> and rewrite the page to highlight that this feature is called “paramset”,
> in the same way we use the term “configset”.
>
> Thoughts/
>
> Eric
>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

> On Feb 6, 2021, at 9:48 AM, Eric Pugh <epugh@opensourceconnections.com> wrote:
>
> “paramsets”, which I think is a really powerful feature that most people don’t know about.

Agreed on that! (see the old example/files for my early paramset usage as I explored that cool capability)

> I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, and rewrite the page to highlight that this feature is called “paramset”, in the same way we use the term “configset”.

+1




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

So...., we may have a problem with the way we use "configset" too. We
are using it to mean a template from which a new collection can be
created (default, techproducts, etc).

But also, if I remember correctly, we allow to share configuration
between live cores using configset parameter in core.properties. And
that is not a template use, because both cores may modify the same
files through API (oops). Though, now that I look at the
documentation, we seem to have collapsed those two. This collapse may
actually be wrong....
https://lucene.apache.org/solr/guide/8_8/defining-core-properties.html

For paramsets, the cool thing is that you can refer to them for update
operations as well. So, they could be used for A/B indexing tests,
etc.

Regards,
Alex.

On Mon, 8 Feb 2021 at 13:03, Erik Hatcher <erik.hatcher@gmail.com> wrote:
>
>
>
> > On Feb 6, 2021, at 9:48 AM, Eric Pugh <epugh@opensourceconnections.com> wrote:
> >
> > “paramsets”, which I think is a really powerful feature that most people don’t know about.
>
> Agreed on that! (see the old example/files for my early paramset usage as I explored that cool capability)
>
> > I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, and rewrite the page to highlight that this feature is called “paramset”, in the same way we use the term “configset”.
>
> +1
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

I have a slightly different view - the thing that creates a paramset, stored in a file called params.json, is called the Request Params API, primarily driven by RequestParams.java, which is why the page is called that. The discrepancy between the naming of the API and the thing it creates has caused this confusion.

The name of the API is in fact more precise than the thing it creates - it’s for request parameters, not other general parameters found in other contexts - while the thing it creates is a shorthand name.

All that’s not to say I object to the change. Just that it wasn’t done the way it is without some thought having gone into it. I honestly just wish the thing “paramsets” was called something else.

(I frankly loathe the tendency to always shorthand “parameters” as “params” in documentation. I’m the one who changed it from being the Request Params API to the Request Parameters API and otherwise did the best I could with the fact that the file is named “params.json” and not “request-params.json” or something similarly more precise to its functionality.)

A few things:

While we’re changing things, is a code change warranted to make the name of the thing “paramsets" more clear in terms of scope? Just throwing it out there.

Usually we don’t just rename pages entirely - there is no 404 redirect mechanism currently in place, so users who may have figured out that the Request Parameters API page = paramsets (as functionality) would find a 404 in the docs from 8.9 forward. Do we care? (At the same time, though, we’re going to need to address this eventually as I have a long list of page renames coming for 9.0.)

Settle on “paramSets” or “paramsets” or “ParamSets” - you used it 2 different ways in your mail alone. It should be one way always.
On Feb 8, 2021, 12:02 PM -0600, Erik Hatcher <erik.hatcher@gmail.com>, wrote:
>
>
> > On Feb 6, 2021, at 9:48 AM, Eric Pugh <epugh@opensourceconnections.com> wrote:
> >
> > “paramsets”, which I think is a really powerful feature that most people don’t know about.
>
> Agreed on that! (see the old example/files for my early paramset usage as I explored that cool capability)
>
> > I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, and rewrite the page to highlight that this feature is called “paramset”, in the same way we use the term “configset”.
>
> +1
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

This is some great perspective, and I love you caught the two ways I wrote it. I do the same with ConfigSets etc….

Plus, we have configoverlay.json out there that is slightly different. Is there a common pattern, like config-overlay.json and request-parameters.json or even request-parameter-sets.json that would make most sense? Wonder what other config files are hanging out there that have different naming schemes?

As for the 404, not sure what the best approach is, however I think it’s better to focus on improving things, and not let that issue prevent us from improving the ref guide…. Plus, DuckDuckGo at least typically has a version number in the url…. I’m still clicking on Solr 6 links when I google “collection api solr ref guide” ;-)

> On Feb 9, 2021, at 10:03 AM, Cassandra Targett <casstargett@gmail.com> wrote:
>
> I have a slightly different view - the thing that creates a paramset, stored in a file called params.json, is called the Request Params API, primarily driven by RequestParams.java, which is why the page is called that. The discrepancy between the naming of the API and the thing it creates has caused this confusion.
>
> The name of the API is in fact more precise than the thing it creates - it’s for request parameters, not other general parameters found in other contexts - while the thing it creates is a shorthand name.
>
> All that’s not to say I object to the change. Just that it wasn’t done the way it is without some thought having gone into it. I honestly just wish the thing “paramsets” was called something else.
>
> (I frankly loathe the tendency to always shorthand “parameters” as “params” in documentation. I’m the one who changed it from being the Request Params API to the Request Parameters API and otherwise did the best I could with the fact that the file is named “params.json” and not “request-params.json” or something similarly more precise to its functionality.)
>
> A few things:
>
> While we’re changing things, is a code change warranted to make the name of the thing “paramsets" more clear in terms of scope? Just throwing it out there.
>
> Usually we don’t just rename pages entirely - there is no 404 redirect mechanism currently in place, so users who may have figured out that the Request Parameters API page = paramsets (as functionality) would find a 404 in the docs from 8.9 forward. Do we care? (At the same time, though, we’re going to need to address this eventually as I have a long list of page renames coming for 9.0.)
>
> Settle on “paramSets” or “paramsets” or “ParamSets” - you used it 2 different ways in your mail alone. It should be one way always.
> On Feb 8, 2021, 12:02 PM -0600, Erik Hatcher <erik.hatcher@gmail.com>, wrote:
>>
>>
>>> On Feb 6, 2021, at 9:48 AM, Eric Pugh <epugh@opensourceconnections.com> wrote:
>>>
>>> “paramsets”, which I think is a really powerful feature that most people don’t know about.
>>
>> Agreed on that! (see the old example/files for my early paramset usage as I explored that cool capability)
>>
>>> I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, and rewrite the page to highlight that this feature is called “paramset”, in the same way we use the term “configset”.
>>
>> +1
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.