I've been curious about what I've been seeing and experimenting with...
There seems to be no set rule whether to use double-quotes or single
quotes, they seem to work interchangeably for all commands using curl or
http. Or, more expectedly can be omitted altogether if the string contains
no spaces.
Camel case (or more specifically upper case) is not supported throughout
for anything not a label. Seems to still work (thankfully) for labels like
hostnames.
Also, might be more of a JSON syntax standard but I'm finding spaces and
tabs between operands are optional and don't affect whether the statement
will work or not.
(1) Your first question seems to be about the curl command. If so, then it
follows shell script rules. In most Unix shell scripts, double-quotes
preserve spaces and such, but allow for variable substitution. Sngle-quotes
also preserve spaces but do not allow variable substitution and preserve
all characters as-is. Example:
So single quotes are usually preferred so that the & and ? characters in
URL parameter lists are not interpreted as shell characters. But if you
want to parameterize a curl command, you may need to use double-quotes for
parts, and single-quotes for the other parts. This is all standard shell
programming.
(2) Camel case is OK for hostnames because hostnames are typically
insensitive. But JSON and ES are case-sensitive.
(3) This is a JSON standard. {"field":"name"} and { "field" : "name" } are
the same, but one or the other is prettier.
On Tuesday, February 18, 2014 11:44:22 AM UTC-8, InquiringMind wrote:
Tony,
(1) Your first question seems to be about the curl command. If so, then it
follows shell script rules. In most Unix shell scripts, double-quotes
preserve spaces and such, but allow for variable substitution. Sngle-quotes
also preserve spaces but do not allow variable substitution and preserve
all characters as-is. Example:
So single quotes are usually preferred so that the & and ? characters in
URL parameter lists are not interpreted as shell characters. But if you
want to parameterize a curl command, you may need to use double-quotes for
parts, and single-quotes for the other parts. This is all standard shell
programming.
(2) Camel case is OK for hostnames because hostnames are typically
insensitive. But JSON and ES are case-sensitive.
(3) This is a JSON standard. {"field":"name"} and { "field" : "name"
} are the same, but one or the other is prettier.
Since JSON and ES do not support upper case,
Would this possibly cause some confusion about bits/Bytes and milli/Mega?
Should it be assumed therefor that ES never supports bits and milli? That
the lower case abbreviations will always apply to the normally capitalized
measures Bytes and Mega?
Thx,
Tony
On Tuesday, February 18, 2014 1:26:06 PM UTC-8, Tony Su wrote:
Thx for the complete answer.
Tony
On Tuesday, February 18, 2014 11:44:22 AM UTC-8, InquiringMind wrote:
Tony,
(1) Your first question seems to be about the curl command. If so, then
it follows shell script rules. In most Unix shell scripts, double-quotes
preserve spaces and such, but allow for variable substitution. Sngle-quotes
also preserve spaces but do not allow variable substitution and preserve
all characters as-is. Example:
So single quotes are usually preferred so that the & and ? characters in
URL parameter lists are not interpreted as shell characters. But if you
want to parameterize a curl command, you may need to use double-quotes for
parts, and single-quotes for the other parts. This is all standard shell
programming.
(2) Camel case is OK for hostnames because hostnames are typically
insensitive. But JSON and ES are case-sensitive.
(3) This is a JSON standard. {"field":"name"} and { "field" : "name"
} are the same, but one or the other is prettier.
JSON and ES both support uppercase. It's just that "FOO" and "foo" are two
completely different field names. Hence, case-sensitive.
In some contexts, ES does not support uppercase. For example, names of
indices. But field names can be in lowercase, uppercase, or mixed case. I
believe that the docs cover this well already.
For distance units, ES will soon support NM for nautical miles. Hence,
12.3nm is reserved for 12.3 nanometers, while 12.3NM will mean 12.3
nautical miles.
OK,
Was just thrown when I see "mb" represent MegaBytes in elasticsearch.yml
Tony
On Tuesday, February 18, 2014 3:12:16 PM UTC-8, InquiringMind wrote:
Tony,
JSON and ES both support uppercase. It's just that "FOO" and "foo" are two
completely different field names. Hence, case-sensitive.
In some contexts, ES does not support uppercase. For example, names of
indices. But field names can be in lowercase, uppercase, or mixed case. I
believe that the docs cover this well already.
For distance units, ES will soon support NM for nautical miles. Hence,
12.3nm is reserved for 12.3 nanometers, while 12.3NM will mean 12.3
nautical miles.
Hmmmm. I see that the
src/main/java/org/elasticsearch/common/unit/ByteSizeUnit.java file defines
the units by uppercase enum name (e.g. MB), while the comments inside the
config/elasticsearch.yml file suggest lowercase (e.g. mb).
Perhaps there's an issue? Or am I reading something incorrectly?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
