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 Grant Ingersoll <gs...@apache.org> on 2009/07/28 12:36:59 UTC
Param Naming and Abbreviations
OK, color me confused about how naming should be done for params.
There clearly seems to be two camps in Solr-land: 1. those who
abbreviate params and 2. those who don't. Pick your sides, please! ;-)
On SOLR-284 and SOLR-769, I had "long" names and Yonik changed them to
be shorter ("uprefix", anyone? Bueller? Yeah, it means unknown
prefix). On SOLR-1237, the general feedback is that evt should be
event and that newSrchr should be newSearcher or new_searcher or
something like that. The SpellCheckComp. tends to be verbose, while
faceting tends to be succinct.
Thus, I'd like to suggest we layout some conventions for naming, as I
personally am confused. Once we do this, we can wiki it up and then
have something to refer others too.
-Grnt Ingrsll (aka Grant Ingersoll)
Re: Param Naming and Abbreviations
Posted by Eric Pugh <ep...@opensourceconnections.com>.
I think it's just if you want a richer syntax for naming things or
not. I agree, it does add complexity because now everything has two
names! But I liken it somewhat to the parameters for a command line
app. I can do "svn update" or "svn up". And when I am first learning
a new command line app, I tend to use the longer name because it is
more english like. But as I run the same command over and over, I
learn the shortcut name.
Eric
On Jul 28, 2009, at 6:57 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
> assuming that there are no name collisions shorter ones are ok for
> request parameters.Having both the options may not really help
>
> On Tue, Jul 28, 2009 at 4:24 PM, Eric
> Pugh<ep...@opensourceconnections.com> wrote:
>> I wonder if we could use either for the various param names that
>> can be used
>> in either solrconfig.xml or passed in via request? Use either
>> "fields" or
>> "fl"? As we add more rich functionality like in the extractor
>> aren't we
>> going to be passing more and more params, and having long names is
>> much
>> easier to read. And then for those optimizing performance, they
>> can swap to
>> the short names?
>>
>>
>> On Jul 28, 2009, at 6:50 AM, Noble Paul നോബിള്
>> नोब्ळ् wrote:
>>
>>> +1 for names in its actual form as long as it is not very long. In
>>> config it is nice to see long names becaase it enhances readability.
>>> But ,for request params, short ones are better because that price is
>>> paid by each request. imagine 'facetQuery' instead of 'fq' or fields
>>> instead of 'fl'
>>>
>>>
>>>
>>> On Tue, Jul 28, 2009 at 4:06 PM, Grant
>>> Ingersoll<gs...@apache.org>
>>> wrote:
>>>>
>>>> OK, color me confused about how naming should be done for
>>>> params. There
>>>> clearly seems to be two camps in Solr-land: 1. those who
>>>> abbreviate
>>>> params
>>>> and 2. those who don't. Pick your sides, please! ;-)
>>>>
>>>> On SOLR-284 and SOLR-769, I had "long" names and Yonik changed
>>>> them to be
>>>> shorter ("uprefix", anyone? Bueller? Yeah, it means unknown
>>>> prefix).
>>>> On
>>>> SOLR-1237, the general feedback is that evt should be event and
>>>> that
>>>> newSrchr should be newSearcher or new_searcher or something like
>>>> that.
>>>> The
>>>> SpellCheckComp. tends to be verbose, while faceting tends to be
>>>> succinct.
>>>>
>>>> Thus, I'd like to suggest we layout some conventions for naming,
>>>> as I
>>>> personally am confused. Once we do this, we can wiki it up and
>>>> then
>>>> have
>>>> something to refer others too.
>>>>
>>>>
>>>> -Grnt Ingrsll (aka Grant Ingersoll)
>>>>
>>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>
>> -----------------------------------------------------
>> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com
>> Free/Busy: http://tinyurl.com/eric-cal
>>
>>
>>
>>
>>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul | Principal Engineer| AOL | http://aol.com
-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com
Free/Busy: http://tinyurl.com/eric-cal
Re: Param Naming and Abbreviations
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
assuming that there are no name collisions shorter ones are ok for
request parameters.Having both the options may not really help
On Tue, Jul 28, 2009 at 4:24 PM, Eric
Pugh<ep...@opensourceconnections.com> wrote:
> I wonder if we could use either for the various param names that can be used
> in either solrconfig.xml or passed in via request? Use either "fields" or
> "fl"? As we add more rich functionality like in the extractor aren't we
> going to be passing more and more params, and having long names is much
> easier to read. And then for those optimizing performance, they can swap to
> the short names?
>
>
> On Jul 28, 2009, at 6:50 AM, Noble Paul നോബിള് नोब्ळ् wrote:
>
>> +1 for names in its actual form as long as it is not very long. In
>> config it is nice to see long names becaase it enhances readability.
>> But ,for request params, short ones are better because that price is
>> paid by each request. imagine 'facetQuery' instead of 'fq' or fields
>> instead of 'fl'
>>
>>
>>
>> On Tue, Jul 28, 2009 at 4:06 PM, Grant Ingersoll<gs...@apache.org>
>> wrote:
>>>
>>> OK, color me confused about how naming should be done for params. There
>>> clearly seems to be two camps in Solr-land: 1. those who abbreviate
>>> params
>>> and 2. those who don't. Pick your sides, please! ;-)
>>>
>>> On SOLR-284 and SOLR-769, I had "long" names and Yonik changed them to be
>>> shorter ("uprefix", anyone? Bueller? Yeah, it means unknown prefix).
>>> On
>>> SOLR-1237, the general feedback is that evt should be event and that
>>> newSrchr should be newSearcher or new_searcher or something like that.
>>> The
>>> SpellCheckComp. tends to be verbose, while faceting tends to be succinct.
>>>
>>> Thus, I'd like to suggest we layout some conventions for naming, as I
>>> personally am confused. Once we do this, we can wiki it up and then
>>> have
>>> something to refer others too.
>>>
>>>
>>> -Grnt Ingrsll (aka Grant Ingersoll)
>>>
>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul | Principal Engineer| AOL | http://aol.com
>
> -----------------------------------------------------
> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com
> Free/Busy: http://tinyurl.com/eric-cal
>
>
>
>
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Param Naming and Abbreviations
Posted by Eric Pugh <ep...@opensourceconnections.com>.
I wonder if we could use either for the various param names that can
be used in either solrconfig.xml or passed in via request? Use either
"fields" or "fl"? As we add more rich functionality like in the
extractor aren't we going to be passing more and more params, and
having long names is much easier to read. And then for those
optimizing performance, they can swap to the short names?
On Jul 28, 2009, at 6:50 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
> +1 for names in its actual form as long as it is not very long. In
> config it is nice to see long names becaase it enhances readability.
> But ,for request params, short ones are better because that price is
> paid by each request. imagine 'facetQuery' instead of 'fq' or fields
> instead of 'fl'
>
>
>
> On Tue, Jul 28, 2009 at 4:06 PM, Grant
> Ingersoll<gs...@apache.org> wrote:
>> OK, color me confused about how naming should be done for params.
>> There
>> clearly seems to be two camps in Solr-land: 1. those who
>> abbreviate params
>> and 2. those who don't. Pick your sides, please! ;-)
>>
>> On SOLR-284 and SOLR-769, I had "long" names and Yonik changed them
>> to be
>> shorter ("uprefix", anyone? Bueller? Yeah, it means unknown
>> prefix). On
>> SOLR-1237, the general feedback is that evt should be event and that
>> newSrchr should be newSearcher or new_searcher or something like
>> that. The
>> SpellCheckComp. tends to be verbose, while faceting tends to be
>> succinct.
>>
>> Thus, I'd like to suggest we layout some conventions for naming, as I
>> personally am confused. Once we do this, we can wiki it up and
>> then have
>> something to refer others too.
>>
>>
>> -Grnt Ingrsll (aka Grant Ingersoll)
>>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul | Principal Engineer| AOL | http://aol.com
-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com
Free/Busy: http://tinyurl.com/eric-cal
Re: Param Naming and Abbreviations
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
+1 for names in its actual form as long as it is not very long. In
config it is nice to see long names becaase it enhances readability.
But ,for request params, short ones are better because that price is
paid by each request. imagine 'facetQuery' instead of 'fq' or fields
instead of 'fl'
On Tue, Jul 28, 2009 at 4:06 PM, Grant Ingersoll<gs...@apache.org> wrote:
> OK, color me confused about how naming should be done for params. There
> clearly seems to be two camps in Solr-land: 1. those who abbreviate params
> and 2. those who don't. Pick your sides, please! ;-)
>
> On SOLR-284 and SOLR-769, I had "long" names and Yonik changed them to be
> shorter ("uprefix", anyone? Bueller? Yeah, it means unknown prefix). On
> SOLR-1237, the general feedback is that evt should be event and that
> newSrchr should be newSearcher or new_searcher or something like that. The
> SpellCheckComp. tends to be verbose, while faceting tends to be succinct.
>
> Thus, I'd like to suggest we layout some conventions for naming, as I
> personally am confused. Once we do this, we can wiki it up and then have
> something to refer others too.
>
>
> -Grnt Ingrsll (aka Grant Ingersoll)
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Param Naming and Abbreviations
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
On Tue, Jul 28, 2009 at 11:55 PM, Chris
Hostetter<ho...@fucit.org> wrote:
>
> : > OK, color me confused about how naming should be done for params. There
> : > clearly seems to be two camps in Solr-land: 1. those who abbreviate params
> : > and 2. those who don't. Pick your sides, please! ;-)
> :
> : Tend towards brevity, but not for the sake of readability.
>
> agreed.
>
> for me it's primarily an issue of huffman encoding:
>
> 1) params that are going to be used all the freaking time, by lots of
> people, frequently when constructing URLs (which will get sent over the
> wire millions of times), should be on the shorter side (q, fl, sort, rows,
> etc...).
>
> 2) params that are going to be used extremely infrequently, and typically
> hardcoded inot a config in the rare cases where they are used, should be
> longer and more verbose (the verbosity being an issue of self documenting
> since people won't be use to seeing them and won't immediately recognize
> them)
amen........
>
>
> (Disclaimer: i freely admit that i screwed the pooch on all those dismax
> params. i came up with those back before it was possible to put defaults
> in solrconfig.xml, so the "keep things that will be in millions of URLs
> going over teh wire" mantra kicked in)
>
>
>
> -Hoss
>
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Param Naming and Abbreviations
Posted by Chris Hostetter <ho...@fucit.org>.
: OK, sounds reasonable, although I suspect your frequency based convention is
: going to be in the eye of the beholder.
absolutely ... but even if we all drank the same koolaid and agreed
perfectly about how short something hsould be based on it's frequency of
use, frequency of use changes. "qt" is a nice short param that is
boardering on deprecation, yet at the time it was introduced it was
explicitly used in almost every request.
hindsight is 20/20.
another problem to keep in mind is local params: even if a param will be
used extremely infrequently, it might be worthwhile to keep it relaly
short if it's *allways* going to be used as a local param inside of the
QParser syntax -- because the qparser will help document the purpose/scope
of hte param. people ocnvinced me that the facet.date.* params were too
short when i first wrote them because date faceting was kind of a niche
thing, and the params needed ot be better self documenting, but now that
we have local params it seems silly to specify them as top level params,
but in local params they see obscenly verbose.
: Has anyone actually documented/tested the "cost" of a URL of 100 chars versus
: one of 200 chars? I don't know much how NIC's work, but I have a hard time
: believing that makes much difference when it comes to packets, buffers, etc.
: especially in comparison to optimizing the response side of things.
i don't have any hard numbers, but i've known people who looked into and
concluded that having shorter URLs does help, but that it wasn't a big
enough deal to go overboard at the expense of readability. common
sense says that all other things being equal you might as well pick a
short one.
As i recall the biggest advantages were:
- smaller keys in HTTP caches improved cache lookup speed.
- reduction in size of request logs
- easier to read various logs when troubleshooting (less linewrap to
confuse people)
: time), I find it curious that so much is put into shortening params in a 200
: char URL (if that) to the point of near unreadability, in some cases, and yet
po-TAY-toe po-TAH-toe ... one url with short param names that you aren't
familiar with may seem unreadable, but when you're skimming thousands of
URLs where the param keys are all the same and what you really care about
are the different *values* it's easier to find the anomolies when the key
names are short.
: the responses (up until the binary response format was added) are so verbose,
: especially for XML (but even JSON isn't all that succinct) and especially when
hey man, why do you think the sml format uses <str> instead of <string> ?
(At one point i remember an argument for only single letter xml node
names, and replacing 'name="..."' with 'n="..."' -- this was back in
the really early days when i wasn't happy that Solar was going to be a
webserver at all and just wanted an in memory service; but both that and
a pure binary response format had already been vetoed by Yonik's boss)
-Hoss
Re: Param Naming and Abbreviations
Posted by Grant Ingersoll <gs...@apache.org>.
On Jul 28, 2009, at 2:25 PM, Chris Hostetter wrote:
>
> : > OK, color me confused about how naming should be done for
> params. There
> : > clearly seems to be two camps in Solr-land: 1. those who
> abbreviate params
> : > and 2. those who don't. Pick your sides, please! ;-)
> :
> : Tend towards brevity, but not for the sake of readability.
>
> agreed.
>
> for me it's primarily an issue of huffman encoding:
>
> 1) params that are going to be used all the freaking time, by lots of
> people, frequently when constructing URLs (which will get sent over
> the
> wire millions of times), should be on the shorter side (q, fl, sort,
> rows,
> etc...).
>
> 2) params that are going to be used extremely infrequently, and
> typically
> hardcoded inot a config in the rare cases where they are used,
> should be
> longer and more verbose (the verbosity being an issue of self
> documenting
> since people won't be use to seeing them and won't immediately
> recognize
> them)
>
>
> (Disclaimer: i freely admit that i screwed the pooch on all those
> dismax
> params. i came up with those back before it was possible to put
> defaults
> in solrconfig.xml, so the "keep things that will be in millions of
> URLs
> going over teh wire" mantra kicked in)
OK, sounds reasonable, although I suspect your frequency based
convention is going to be in the eye of the beholder.
[somewhat of an aside, and a rant :-) ]
Has anyone actually documented/tested the "cost" of a URL of 100 chars
versus one of 200 chars? I don't know much how NIC's work, but I have
a hard time believing that makes much difference when it comes to
packets, buffers, etc. especially in comparison to optimizing the
response side of things.
While I'm not for wasting bits (except in email, where I waste them
all the time), I find it curious that so much is put into shortening
params in a 200 char URL (if that) to the point of near unreadability,
in some cases, and yet the responses (up until the binary response
format was added) are so verbose, especially for XML (but even JSON
isn't all that succinct) and especially when you throw in
highlighting, MLT, etc. Seems to me if we are optimizing for over the
wire, we'd be a whole lot better off making sure all the various
clients supported the binary response format then making sure "event"
is abbreviated to "evt". It's just that I've seen over and over the
cost savings one gets from not having to deal with XML (or even JSON,
which we just learned over in Mahout). Don't get me wrong, Solr needs
an XML response, it's just that the only client that should be using
it is the Human one (i.e. via the browser or curl, debugging, etc.) as
it is a waste of time when you control both sides of the pipe and are
a program.
-Grnt (trying to save bits, one 'a' at a time, oops, there goes more)
Re: Param Naming and Abbreviations
Posted by Chris Hostetter <ho...@fucit.org>.
: > OK, color me confused about how naming should be done for params. There
: > clearly seems to be two camps in Solr-land: 1. those who abbreviate params
: > and 2. those who don't. Pick your sides, please! ;-)
:
: Tend towards brevity, but not for the sake of readability.
agreed.
for me it's primarily an issue of huffman encoding:
1) params that are going to be used all the freaking time, by lots of
people, frequently when constructing URLs (which will get sent over the
wire millions of times), should be on the shorter side (q, fl, sort, rows,
etc...).
2) params that are going to be used extremely infrequently, and typically
hardcoded inot a config in the rare cases where they are used, should be
longer and more verbose (the verbosity being an issue of self documenting
since people won't be use to seeing them and won't immediately recognize
them)
(Disclaimer: i freely admit that i screwed the pooch on all those dismax
params. i came up with those back before it was possible to put defaults
in solrconfig.xml, so the "keep things that will be in millions of URLs
going over teh wire" mantra kicked in)
-Hoss
Re: Param Naming and Abbreviations
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jul 28, 2009, at 6:36 AM, Grant Ingersoll wrote:
> OK, color me confused about how naming should be done for params.
> There clearly seems to be two camps in Solr-land: 1. those who
> abbreviate params and 2. those who don't. Pick your sides,
> please! ;-)
Tend towards brevity, but not for the sake of readability.
Erik