Should Index#get_settings post-process the API response?

[drdaeman]

I've noticed that Index#get_settings doesn't post-process the results, thus its behavior is a bit inconsistent as it's going to return deprecated attributes for some indices. If not accounted for, such behavior may lead to issues like this: algolia/algoliasearch-rails#357

I'd suggest "modernizing" the response by replacing the deprecated keys with their modern synonyms, like the Python Algolia client library does. With such change "attributesToIndex" would always become "searchableAttributes", etc.

I'd love to contribute a PR, but want to make sure I'd do the right thing. The proposal above could be considered a breaking change. While some users seem to expect the settings to be trivially mergeable, some users may expect the inconsistency that is currently observed in the responses. I'm not really sure what determines if the Algolia API returns the legacy attribute or a new one - I believe this is undocumented (although maybe I just haven't found this).

As an alternative solution, it could be that set_settings should transparently remove the redundant attributes, trying to "just work" when the intent is unambiguous. So if there are both "attributesToIndex" and "searchableAttributes", with exactly the same value, the client library can be tolerant and "fix" the request (while issuing a warning). Obviously, it should not make any guesses and fail if the values differ. That would solve naively merged setting objects that don't really change (see the linked algoliasearch-rails issue), while avoid breaking things.

It is also possible that this normalization doesn't belong to this library at all, or should be a helper function.

Any thoughts or suggestions how it's best to approach this?
Thanks!

[chloelbn]

This feature is implemented in v2 that will be out in a few weeks