Deprecate camelCasing

[clintongormley]

Elasticsearch allows all parameters to be passed with underscores or as camelCase (except where somebody has forgotten to handle the camelCase variant, and isn't using parseField #8964).

Also, the keys in responses can be rendered in camel case by passing ?case=camelCase, except that rendering seems inconsistent, eg:

{
   "took": 2,
   "timedOut": false,
   "Shards": {
      "total": 10,
      "successful": 10,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "maxScore": 1,
      "hits": [
         {
            "Index": "t",
            "Type": "t",
            "Id": "1",
            "Score": 1,
            "_source": {
               "foo_bar": "foo bar baz"
            }
         }
      ]
   }
}

Does anybody actually use the camelCase option? Almost all of the documentation uses the underscore version of parameters, and having a single set of accepted parameters (and responses) seems less likely to cause confusion than the current situation.

I'd recommend deprecating camelcase in 2.0 and removing it in 3.0, but labelling this ticket for discussion.

[mikemccand]

+1

[nik9000]

+1

[dakrone]

+1, what about deprecate in 1.5 and remove in 2.0?

[clintongormley]

@dakrone i'd rather give people time to make their adjustments. the use of camelcase in 2.0 would trigger deprecation warnings (see #8963)

[dadoonet]

+1 to deprecate in 1.5 but remove in 2.1 or 3.0.
I'd prefer deprecate sooner instead of later.

[jpountz]

So everyone seems to agree on this issue, the question is more about when the deprecation starts and when we remove. We can only deprecate as of 2.0 because of #8963 and then remove in 2.x. Even though it is a minor release, I would agree with David we should do it sooner rather than later, especially if we have it deprecated from the first 2.0 release?

[uboness]

I don't think #8963 should stop us form deprecating (not having this warning didn't stop us before). Also, I don't think many ppl are using camelCasing or are even aware of it. Also it doesn't feel right removing something like this in between minor versions.

+1 on deprecation for 1.5 and remove on 2.0

[rjernst]

+1 from me as well to deprecate in 1.5 and remove in 2.0.

[clintongormley]

This has been hanging around for way too long. Let's just bite the bullet and deprecate camel case in 5.0 (with deprecation logging) and remove it in 6.0

[bleskes]

+1 . I think we should evaluate the BWC implications for stored data (percolator? mapping?) but I hope we can find ways to convert things …

On 06 Apr 2016, at 11:52, Clinton Gormley notifications@github.com wrote:

This has been hanging around for way too long. Let's just bite the bullet and deprecate camel case in 5.0 (with deprecation logging) and remove it in 6.0

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[jpountz]

In 5.0 mappings serialize themselves using lowercase (we do not just copy the user input) and the percolator now stores the binary representation of a query, so I think we are fine from this perspective.

[bleskes]

I meant things already stored in indices. Good to know we convert incoming input.

On 07 Apr 2016, at 11:31, Adrien Grand notifications@github.com wrote:

In 5.0 mappings serialize themselves using lowercase (we do not just copy the user input) and the percolator now stores the binary representation of a query, so I think we are fine from this perspective.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[clintongormley]

@rjernst can this issue be closed now?

[rjernst]

@clintongormley As I was preparing the removal of all camel case from master, I found some other cases. One additional deprecation is in #17875, however, there are other places that I found are not using ParseField, and have their own custom parsing logic which includes many variations of settings names (including adding _, with and without camelCase), eg in BulkRequest. Not sure how best to weed out those cases (or even how to handle BulkRequest specifically).

[clintongormley]

@rjernst there's another issue to deal with bulk request params (#13377)

Also, I wonder if analyzer/token filter/etc names are handled with their own camel case code?

[rjernst]

@clintongormley Not sure I understand your comment about analyzer/etc. I added deprecation for the automatic addition of camel case analysis names in #17800.