Deprecate lenient booleans #22716

danielmitterdorfer · 2017-01-20T13:52:07Z

Elasticsearch 6.0 removes support for lenient
booleans (see #22200). With this commit we
deprecate all usages of non-strict booleans in
Elasticsearch 5.x so users can already spot
improper usages.

Relates #22200
Relates #22696

Elasticsearch 6.0 removes support for lenient booleans (see elastic#22000). With this commit we deprecate all usages of non-strict booleans in Elasticsearch 5.x so users can already spot improper usages. Relates elastic#22000 Relates elastic#22696

danielmitterdorfer · 2017-01-20T13:53:39Z

@nik9000, @dakrone: Related to #22200, this PR adds deprecation warnings in 5.x for all occurrences of lenient booleans. As you've reviewed #22200, could you please also review this one?

dakrone

LGTM, I left some minor comments

dakrone · 2017-01-20T16:50:52Z

core/src/main/java/org/elasticsearch/action/support/AutoCreateIndex.java

@@ -116,6 +119,10 @@ private AutoCreate(String value) {
            List<Tuple<String, Boolean>> expressions = new ArrayList<>();
            try {
                autoCreateIndex = Booleans.parseBooleanExact(value);
+                if (Booleans.isStrictlyBoolean(value) == false) {
+                    DEPRECATION_LOGGER.deprecated("Expected a boolean for setting [{}] but got [{}]",


I think one should be Expected a boolean [true/false] or index name pattern for setting [{}] but got [{}] since it technically takes more than just a boolean. Otherwise anyone reading the deprecation log could think it doesn't support index name patterns

Makes sense. I'll change the wording.

dakrone · 2017-01-20T16:52:04Z

core/src/main/java/org/elasticsearch/action/support/IndicesOptions.java

-                lenientNodeBooleanValue(ignoreUnavailableString, defaultSettings.ignoreUnavailable()),
-                lenientNodeBooleanValue(allowNoIndicesString, defaultSettings.allowNoIndices()),
+                lenientNodeBooleanValue(ignoreUnavailableString, "ignore_unavailable", defaultSettings.ignoreUnavailable()),
+                lenientNodeBooleanValue(allowNoIndicesString, "allow_no_indices", defaultSettings.allowNoIndices()),


Wish these were static vars instead of hardcoded strings since they're scattered all over this file and the potential for typos is high, but it's not really in the scope of this PR :-/

dakrone · 2017-01-20T16:55:41Z

core/src/main/java/org/elasticsearch/common/settings/Setting.java

+        boolean booleanValue = Booleans.parseBooleanExact(value);
+        if (Booleans.isStrictlyBoolean(value) == false) {
+            DeprecationLogger deprecationLogger = new DeprecationLogger(Loggers.getLogger(Setting.class));
+            deprecationLogger.deprecated("Expected a boolean for setting [{}] but got [{}]", key, value);


"Expected a boolean" -> "Expected a boolean [true/false]"

I see this is all over the place, so if you don't want to add it, that's okay with me. It's up to you :)

I think your suggestion is more user-friendly, so I'll change it in all places.

dakrone · 2017-01-20T16:56:49Z

core/src/main/java/org/elasticsearch/common/settings/Settings.java

+        Boolean booleanValue = Booleans.parseBooleanExact(rawValue, defaultValue);
+        if (rawValue != null && Booleans.isStrictlyBoolean(rawValue) == false) {
+            DeprecationLogger deprecationLogger = new DeprecationLogger(Loggers.getLogger(Settings.class));
+            deprecationLogger.deprecated("Expected a boolean for setting [{}] but got [{}]", setting, rawValue);


Same here about adding [true/false] to the message

dakrone · 2017-01-20T16:58:43Z

core/src/main/java/org/elasticsearch/common/xcontent/support/AbstractXContentParser.java

        } else if (token == Token.VALUE_STRING) {
-            return Booleans.parseBoolean(textCharacters(), textOffset(), textLength(), false /* irrelevant */);
+            rawValue = new String(textCharacters(), textOffset(), textLength());


I believe this might need a charset passed into the String constructor?

We can only specify a Charset when constructing a String from a byte[] but not when constructing from a char[]. The reason is that in Java a char always represents a Unicode scalar value whereas a byte does not (necessarily).

dakrone · 2017-01-20T16:59:48Z

core/src/main/java/org/elasticsearch/common/xcontent/support/XContentMapValues.java

+            booleanValue = (Boolean) node;
+        } else if (node instanceof Number) {
+            interpretedAsLenient = true;
+            booleanValue = ((Number) node).intValue() != 0;


So glad we're getting rid of this so someone doesn't think -1 == false when it actually means true...

dakrone · 2017-01-20T17:00:44Z

core/src/main/java/org/elasticsearch/common/xcontent/support/XContentMapValues.java

+            booleanValue = ((Number) node).intValue() != 0;
+        } else {
+            String value = node.toString();
+            booleanValue = !(value.equals("false") || value.equals("0") || value.equals("off"));


Can you change this ! to == false so eyes don't skip over it? :)

Actually, I think this is missing parsing "no" as false, in which case this would be breaking, perhaps this should use the helpers in Booleans instead?

Hmm I see the original behavior had this inconsistency also (not parsing "no" like all the other boolean methods do)... not sure whether we should try to re-add the consistency or keep the broken behavior.

I'm in favor of re-adding the "no" parsing to be consistent as a semi-bugfix, what do you think? (it's going away in 6.0 anyway...)

You are right. This is the original behavior and I just moved code around. I have really mixed feelings about fixing it now because it could lead to bugs in client applications that are very hard to find. Despite this I am still slightly in favor of fixing it too because this problem would appear anyway at latest in 6.0. However, I will fix it in a separate commit after merging this PR.

…eans

In #22716 we significantly increased the variety of boolean representations that are created by the BWC script. The script and the related tests have only been backported to Elasticsearch 5.3 though. Hence, if we generate an index with a great variety of boolean representation but `RestoreBackwardsCompatIT#testOldSnapshot()` tests only one representation it has to fail. With this commit we regenerate the BWC indices for 5.2.0 and 5.2.1 with the older version of the script (which is present on the 5.2 branch) and only generates one representation of boolean fields as expected by the test.

Deprecate lenient booleans

9827118

Elasticsearch 6.0 removes support for lenient booleans (see elastic#22000). With this commit we deprecate all usages of non-strict booleans in Elasticsearch 5.x so users can already spot improper usages. Relates elastic#22000 Relates elastic#22696

danielmitterdorfer added :Core/Infra/Core Core issues without another label >deprecation v5.3.0 labels Jan 20, 2017

danielmitterdorfer requested review from dakrone and nik9000 January 20, 2017 13:52

dakrone approved these changes Jan 20, 2017

View reviewed changes

danielmitterdorfer added 2 commits January 23, 2017 13:46

Incorporate review feedback

4593b0b

Merge remote-tracking branch 'origin/5.x' into deprecate-lenient-bool…

9b237a5

…eans

danielmitterdorfer merged commit 9946abf into elastic:5.x Jan 23, 2017

danielmitterdorfer removed the request for review from nik9000 January 23, 2017 14:00

Deprecate lenient booleans #22716

Deprecate lenient booleans #22716

Uh oh!

Conversation

danielmitterdorfer commented Jan 20, 2017 • edited by clintongormley Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danielmitterdorfer commented Jan 20, 2017

Uh oh!

dakrone left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

danielmitterdorfer commented Jan 20, 2017 •

edited by clintongormley

Loading