Make boolean conversion strict #22200

danielmitterdorfer · 2016-12-15T18:08:47Z

This PR removes all leniency in the conversion of Strings to booleans: "true" is converted to the boolean value true, "false" is converted to the boolean value false. Everything else raises an error.

This applies to:

All settings (index settings, cluster settings)
Boolean values in the REST API
Documents

Exceptions are:

For indices created before Elasticsearch 6, we still apply the old coercion logic (but we add deprecation logging).
We allow to omit the value "true" for request parameters in the REST API, i.e. ?pretty is interpreted as ?pretty=true.

Noteworthy / to discuss:

Bucket term aggregations on boolean fields continue to use 1 and 0 for the key, and the strings "true" and "false" for the key_as_string (I think that's fine).
Existing index templates can be read after an upgrade but creating a new index based on an index template with invalid boolean values will fail (see below for a discussion of the tradeoffs).

Example scenario (the lowercase field of my_custom_pattern_analyzer is a boolean field):

Create the following index template on Elasticsearch 5.x:

DELETE /_template/default_template

PUT /_template/default_template
{
  "template": "*",
    "settings": {
        "analysis": {
            "analyzer": {
                "my_custom_pattern_analyzer": {
                    "type": "pattern",
                    "lowercase": 0
                }
            }
        }    
    }  
}

Upgrade to Elasticsearch 6
Create the following index:

DELETE /test

PUT /test

Result: Creating the index will fail, because the lowercase setting is invalid for a 6.x index.

Analysis: When a new index is created, MetaDataCreateIndexService will load all matching index templates, merge them settings and apply request settings overrides. By the time the index is created we have no clue where the affected setting came from and before that we don't have enough information to know a value's type.

Discussion:

I can think of the following options to address this:

Keep the code as it is but highlight this specific behavior in the migration docs (and the migration plugin?) to ensure that users are aware and can take appropriate action before the upgrade.
Be lenient when we find a matching index template (I'd rather avoid this).
Add additional metadata to index templates to store the Elasticsearch version when an index template has been created. Also reimplement the merging logic so we know a setting's origin.

To me, option 1 seems the only feasible one (and the doc update is contained in the PR) but I want to put that up for discussion.

This PR removes all leniency in the conversion of Strings to booleans: "true" is converted to the boolean value `true`, "false" is converted to the boolean value `false`. Everything else raises an error.

jasontedor · 2016-12-15T18:30:38Z

+1

This:

on -> true
no -> false

has always offended me; it's too easy to make a typo.

nik9000

Left some comments. I think it is a good choice.

nik9000 · 2016-12-15T20:21:23Z

core/src/main/java/org/elasticsearch/common/Booleans.java

            return true;
        }
-
-        throw new IllegalArgumentException("Failed to parse value [" + value + "] cannot be parsed to boolean [ true/1/on/yes OR false/0/off/no ]");
+        throw new IllegalArgumentException("Failed to parse value [" + value + "] as boolean (only 'true' and 'false' are allowed)");


I think "Failed to parse value [" + value + "] as only [true] or [false] are allowed." is a easier to read.

nik9000 · 2016-12-15T20:22:15Z

core/src/main/java/org/elasticsearch/common/Booleans.java

     */
    public static boolean isExplicitFalse(String value) {
-        return value != null && (value.equals("false") || value.equals("0") || value.equals("off") || value.equals("no"));
+        return value != null && value.equals("false");


"false".equals(value)?

nik9000 · 2016-12-15T20:25:46Z

core/src/main/java/org/elasticsearch/rest/RestRequest.java

@@ -196,7 +196,13 @@ public long paramAsLong(String key, long defaultValue) {

    @Override
    public boolean paramAsBoolean(String key, boolean defaultValue) {
-        return Booleans.parseBoolean(param(key), defaultValue);
+        String rawParam = param(key);
+        // treat the sheer presence of a parameter as "true"


Maybe "Treat empty string as true because that allows the presence of the url parameter to mean "turn this on"".

nik9000 · 2016-12-15T20:26:22Z

core/src/test/java/org/elasticsearch/common/BooleansTests.java

-        String[] booleans = new String[]{"true", "false", "on", "off", "yes", "no", "0", "1"};
-        String[] notBooleans = new String[]{"11", "00", "sdfsdfsf", "F", "T"};
+        String[] booleans = new String[]{"true", "false"};
+        String[] notBooleans = new String[]{"11", "00", "sdfsdfsf", "F", "T", "on", "off", "yes", "no", "0", "1"};


+++++++++++

nik9000 · 2016-12-15T20:26:53Z

core/src/test/java/org/elasticsearch/common/BooleansTests.java

        assertThat(Booleans.isBoolean(null, 0, 1), is(false));

        for (String b : booleans) {
            String t = "prefix" + b + "suffix";
-            assertThat("failed to recognize [" + b + "] as boolean", Booleans.isBoolean(t.toCharArray(), "prefix".length(), b.length()), Matchers.equalTo(true));
+            assertThat("failed to recognize [" + b + "] as boolean",


assertTrue?

nik9000 · 2016-12-15T20:27:26Z

core/src/test/java/org/elasticsearch/common/BooleansTests.java

+        assertThat(Booleans.parseBoolean("true", randomFrom(Boolean.TRUE, Boolean.FALSE, null)), is(true));
+        assertThat(Booleans.parseBoolean("false", randomFrom(Boolean.TRUE, Boolean.FALSE, null)), is(false));
+        expectThrows(IllegalArgumentException.class,
+            () -> Booleans.parseBoolean("true".toUpperCase(Locale.ROOT),randomFrom(Boolean.TRUE, Boolean.FALSE, null)));


s/"true".toUpperCase(Locale.ROOT)/TRUE/?

nik9000 · 2016-12-15T20:28:25Z

docs/reference/migration/migrate_6_0/settings.asciidoc

@@ -1,6 +1,12 @@
 [[breaking_60_settings_changes]]
 === Settings changes

+==== General changess
+
+Previously, Elasticsearch recognized the strings "true","false","on","off","yes","no","0","1" as booleans. Elasticsearch 6.0 recognizes only


true, false, on, off`....

With backticks, I mean.

danielmitterdorfer · 2016-12-16T08:27:31Z

@nik9000 Thanks for your comments. They all make sense and I'll address them.

clintongormley · 2016-12-16T08:51:57Z

I don't care about strict booleans in settings, mappings, query string params, etc. The one place I do care about it is in boolean fields in documents.

My initial thought was: we allow coercion on other field types by default, why are we suddenly strict on boolean fields? Why not also accept 0/1 as false/true? Of course in Perl, the numbers 0 and 1 might be rendered as strings in JSON, so you'd need to accept "0" and "1" as well. But "0" is true in many languages, and in fact 0 is true in Ruby as well.

In other words, whatever coercion you allow, somebody is going to be surprised. Much better to shout loud, shout early. So what I'd like to see:

Deprecation logging for any use of boolean values which are not true, false,"true", or "false"
This change is made for 6.0, but only for new indices.
The boolean semantics don't change for indices created in 5.x, but they continue to emit deprecation logging

tlrx · 2016-12-16T08:53:47Z

core/src/main/java/org/elasticsearch/common/Booleans.java

-     * Returns <code>true</code> iff the value is either of the following:
-     *   <tt>false</tt>, <tt>0</tt>, <tt>off</tt>, <tt>no</tt>
-     *   otherwise <code>false</code>
+     * @return <code>true</code> iff the value is <tt>false</tt>, otherwise <code>false</code>.
     */
    public static boolean isExplicitFalse(String value) {


I guess it could be renamed to isFalse() / isTrue() now

nik9000 · 2016-12-16T19:13:35Z

Deprecation logging for any use of boolean values which are not true, false,"true", or "false"

Everywhere. In the API and in documents.

This change is made for 6.0, but only for new indices.

That makes this much more complicated but I think it is worth it. @danielmitterdorfer, for testing see this trick that lets you create an index on the current version that "looks like" it was made on a previous version. It makes testing this kind of thing much easier.

danielmitterdorfer · 2016-12-19T12:28:54Z

I've addressed all initial review comments now (although I did not comment on each one). Thanks to @nik9000 for the pointer to the BWC trick. I'll start now to add BWC.

clintongormley · 2016-12-19T14:42:37Z

This change is made for 6.0, but only for new indices.

To clarify, I meant this comment for boolean fields only, not for other booleans associated with an index (including mappings, settings etc).

danielmitterdorfer · 2017-01-10T09:29:37Z

@nik9000 Can you spare some cycles on the review?

nik9000 · 2017-01-10T21:14:25Z

@nik9000 Can you spare some cycles on the review?

Sure! I was hoping someone else would give it a deep dive but I will. Not today, though. I'll save it for tomorrow I think!

nik9000

I left a bunch of comments, mixing the mundane ("please add a space here") with the important ("we should remove the default here" and "I think we should support this behavior you've documented as unsupported").

nik9000 · 2017-01-11T18:10:50Z

...in/java/org/elasticsearch/action/admin/cluster/snapshots/restore/RestoreSnapshotRequest.java

+                try {
+                    partial(nodeBooleanValue(entry.getValue()));
+                } catch (IllegalArgumentException ex) {
+                    throw new IllegalArgumentException("Could not convert [partial] to boolean.", ex);


I wonder if it is worth having a version of nodeBooleanValue that tasks a string for the name of the field being converted. I know we have a few methods like that in other places.

Ah, that's a good idea. I'll need to check the call-sites.

nik9000 · 2017-01-11T18:18:18Z

core/src/main/java/org/elasticsearch/common/Booleans.java

+     * @param offset offset to start
+     * @param length length to check
+     *
+     * @deprecated Only kept to provide automatic upgrades for pre 6.0 indices. Use {@link #isBoolean(char[], int, int)} instead.


I don't believe this is only kept for BWC. You use this to parse _source above.

I checked usages of all Booleans.*lenient() but I didn't see the code you're referring to. However, if it's just about the wording of the Javadoc I'm fine with changing it. The gist of the Javadocs should be: "Don't use it, we just need it during a transition phase and it will be removed."

I think you use it indirectly through parser. isBooleanValueLenient.

Oh, that one. XContentParser#isBooleanValueLenient() is here for BWC as well so I think the comment is fine.

nik9000 · 2017-01-11T18:20:33Z

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

+     */
+    @Deprecated
+    public Boolean getAsBooleanLenientForPreEs6Indices(Version indexVersion, String setting, Boolean defaultValue) {
+        if (indexVersion.before(Version.V_6_0_0_alpha1_UNRELEASED)) {


In the test for this you can assert that the minimum supported version is before 6.0.0_alpha1 with a message to remove the whole method after the assertion fails.

Clever! I'll do that.

nik9000 · 2017-01-11T18:20:54Z

core/src/main/java/org/elasticsearch/common/xcontent/XContentParser.java

     */
-    boolean isBooleanValue() throws IOException;
+    @Deprecated
+    boolean isBooleanValueLenient() throws IOException;


Same thing as last comment.

nik9000 · 2017-01-11T18:21:32Z

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

+            //Only emit a warning if the setting's value is not a proper boolean
+            final String value = get(setting, "false");
+            if (Booleans.isBoolean(value) == false) {
+                @SuppressWarnings("deprecation")


I don't believe it does anything to suppress deprecated warnings when you are in a deprecated method.

My rationale around this whole suppression was: deprecated methods get the @Deprecate annotation but I don't want to spit out unnecessary additional deprecation warnings when I (intentionally) call deprecated API in these methods.

Fine by me.

nik9000 · 2017-01-11T18:34:42Z

core/src/test/java/org/elasticsearch/action/get/MultiGetRequestTests.java

+
+    public void testAddWithValidSourceValueIsAccepted() throws Exception {
+        XContentParser parser = createParser(XContentFactory.jsonBuilder()
+            .startObject()


Thanks for indenting!

nik9000 · 2017-01-11T18:35:23Z

core/src/test/java/org/elasticsearch/cluster/SimpleClusterStateIT.java

-                .addMapping("type1", XContentFactory.jsonBuilder().startObject().startObject("type1").startObject("properties")
-                        .startObject("field2").field("type", "text").field("store", "no").endObject()
-                        .endObject().endObject().endObject())
+                .addMapping("type1", XContentFactory.jsonBuilder()


nik9000 · 2017-01-11T18:40:07Z

core/src/test/java/org/elasticsearch/rest/BaseRestHandlerTests.java

@@ -160,8 +160,8 @@ protected RestChannelConsumer prepareRequest(RestRequest request, NodeClient cli
        final HashMap<String, String> params = new HashMap<>();
        params.put("format", randomAsciiOfLength(8));
        params.put("filter_path", randomAsciiOfLength(8));
-        params.put("pretty", randomAsciiOfLength(8));
-        params.put("human", randomAsciiOfLength(8));
+        params.put("pretty", "");


randomFrom("true", "false", "", null)?

It looks like the test didn't care what the value was.

Correct; the test did not care about that but the handler still parses the value so I think it makes sense to randomize it.

nik9000 · 2017-01-11T18:43:02Z

docs/reference/migration/migrate_6_0/mappings.asciidoc

+mappings immediately and can also read existing documents but for example the following operations will not be possible (even on
+pre-6.0 indices):
+
+* Adding new documents to existing indices that violate the strict `boolean` coercion rules.


I think this is possible, right? Or, at least, we want it to be. If the index is pre-6.0 adding a boolean field like "field": 0 should accept it as a boolean.

Yes, this still works (just verified locally). :) I'll remove that section from the docs.

nik9000 · 2017-01-11T18:43:46Z

docs/reference/migration/migrate_6_0/mappings.asciidoc

+pre-6.0 indices):
+
+* Adding new documents to existing indices that violate the strict `boolean` coercion rules.
+* Creating new indices from index templates that violate the strict `boolean` coercion rules.


I think I'd rewrite this in some way, merging it with the sentence above, saying something like "even new documents created with old templates."

I've rewritten that part (and the sentence above is gone now).

danielmitterdorfer · 2017-01-13T09:58:27Z

@nik9000 Thanks for your comments, very helpful! I've pushed a few more commits that address all your comments.

nik9000

LGTM but I'm glad it'll get another set of eyes before merging.

nik9000 · 2017-01-17T15:52:45Z

core/src/main/java/org/elasticsearch/cluster/metadata/IndexMetaData.java

@@ -1217,7 +1217,8 @@ public static IndexMetaData fromXContent(XContentParser parser) throws IOExcepti
     * {@link #isIndexUsingShadowReplicas(org.elasticsearch.common.settings.Settings)}.
     */
    public static boolean isOnSharedFilesystem(Settings settings) {
-        return settings.getAsBoolean(SETTING_SHARED_FILESYSTEM, isIndexUsingShadowReplicas(settings));
+        Version version = settings.getAsVersion(SETTING_VERSION_CREATED, Version.CURRENT);


Are you sure it is a good idea to have a default here? This shouldn't be missing in production, right?

I missed that one and will change it.

nik9000 · 2017-01-17T15:53:40Z

core/src/main/java/org/elasticsearch/common/TriFunction.java

+ * @param <U> the type of the third argument
+ * @param <R> the return type
+ *
+ * @since 1.8


I don't think this is @since anything.

That was a leftover; I'll remove it.

nik9000 · 2017-01-17T15:55:20Z

core/src/main/java/org/elasticsearch/index/IndexModule.java

@@ -256,7 +257,7 @@ public void addIndexStore(String type, Function<IndexSettings, IndexStore> provi
     * @param name Name of the SimilarityProvider
     * @param similarity SimilarityProvider to register


I think I'd prefer to have an interface for building the similarity. That way you can document what the two Settings are.

I thought about this too but I figured that given it is temporary (i.e. this will be again a BiFunction after the cleanup task #22298 is done) it might be ok. But I might need to ponder once more.

dakrone

LGTM, I left pretty minor comments which are pretty much optional, happy to have this go in!

dakrone · 2017-01-17T17:18:21Z

core/src/main/java/org/elasticsearch/cluster/metadata/IndexMetaData.java

@@ -1217,7 +1217,8 @@ public static IndexMetaData fromXContent(XContentParser parser) throws IOExcepti
     * {@link #isIndexUsingShadowReplicas(org.elasticsearch.common.settings.Settings)}.
     */
    public static boolean isOnSharedFilesystem(Settings settings) {
-        return settings.getAsBoolean(SETTING_SHARED_FILESYSTEM, isIndexUsingShadowReplicas(settings));
+        Version version = settings.getAsVersion(SETTING_VERSION_CREATED, Version.CURRENT);
+        return settings.getAsBooleanLenientForPreEs6Indices(version, SETTING_SHARED_FILESYSTEM, isIndexUsingShadowReplicas(settings));


Shouldn't the settings object here already have access to the Version by retrieving the version inside the getAsBooleanLenientForPreEs6Indices method, so it can be skipped retrieving it outside of the method?

Maybe an additional arity version that didn't require the version and automatically looked it up from itself, that could save you some lookups (if you want)

I use the indexCreatedVersion of IndexMetaData now (just had to turn this into an instance method) and have also provided an overloaded version without parameters.

dakrone · 2017-01-17T17:22:39Z

core/src/main/java/org/elasticsearch/common/Booleans.java

    }

    public static Boolean parseBoolean(String value, Boolean defaultValue) {
+        if (value == null || value.length() == 0) {


I think value.length() == 0 here should be String.hasText(value), so it checks for " " and uses the default value for it.

I've used Strings.hasText(value) in all places where it's possible.

dakrone · 2017-01-17T17:24:54Z

core/src/main/java/org/elasticsearch/common/Booleans.java

+        if (value == null || value.length() == 0) {
+            return defaultValue;
+        }
+        return parseBoolean(value);
    }

    public static Boolean parseBoolean(String value, Boolean defaultValue) {


Is there a case where we need a @Nullable version of parseBoolean and a non-nullable version? Do we use the null places?

Yes, there are some places indeed. For example, we use it when parsing REST request parameters in RestActions#urlParamsToQueryBuilder(RestRequest).

dakrone · 2017-01-17T17:27:10Z

core/src/main/java/org/elasticsearch/common/Booleans.java

+     * @deprecated Only kept to provide automatic upgrades for pre 6.0 indices. Use {@link #parseBoolean(char[], int, int, boolean)} instead
+     */
+    @Deprecated
+    public static boolean parseBooleanLenient(char[] text, int offset, int length, boolean defaultValue) {


Does this need to be public, or can we make it private to this class and force everyone to go through the String version of the parseBooleanLenient? (I did a cursory glance and didn't see usages, but it's possible I missed some)

Ah nevermind, I see where we use it :-/

dakrone · 2017-01-17T17:28:55Z

core/src/main/java/org/elasticsearch/common/TriFunction.java

+ * @since 1.8
+ */
+@FunctionalInterface
+public interface TriFunction<S, T, U, R> {


I'm curious why the S, T, and U instead of something like A, B, and C?

Because TriFunction is really just java.util.BiFunction plus an additional parameter.

dakrone · 2017-01-17T17:33:41Z

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

+        try {
+            return nodeBooleanValue(node, defaultValue);
+        } catch (IllegalArgumentException ex) {
+            throw new IllegalArgumentException("Could not convert [" + name + "] to boolean.", ex);


It's super minor, but I think we usually don't include punctuation at the end of exception messages (the .)

dakrone · 2017-01-17T17:34:42Z

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

-        if (node instanceof Number) {
-            return ((Number) node).intValue() != 0;
+    public static boolean nodeBooleanValue(Object node, boolean defaultValue) {
+        String nodeValue = node != null ? node.toString() : null;


Also minor, but I think I'd prefer node == null ? null : node.toString() because it requires less negative-resolving in my brain, up to you though.

Out of curiosity I ran a grep over the codebase and your idiom wins (685 vs. 240 matches). Personally I prefer "my" style but as I value consistency more, I'll happily change it. :)

dakrone · 2017-01-17T17:41:33Z

core/src/main/java/org/elasticsearch/index/mapper/TypeParsers.java

-        // TODO: remove this leniency in 6.0
-        if (BOOLEAN_STRINGS.contains(node.toString()) == false) {
-            DEPRECATION_LOGGER.deprecated("Expected a boolean for property [{}] but got [{}]", name, node);
+    //TODO 22298: Remove this method and have all call-sites use <code>XContentMapValues.nodeBooleanValue(node)</code> directly.


You could add an assert that it's not ES 7.x here so we know to remove it

dakrone · 2017-01-17T17:54:27Z

core/src/main/java/org/elasticsearch/index/mapper/TypeParsers.java

-    private static void parseAnalyzersAndTermVectors(FieldMapper.Builder builder, String name, Map<String, Object> fieldNode, Mapper.TypeParser.ParserContext parserContext) {
+
+    private static void parseAnalyzersAndTermVectors(FieldMapper.Builder builder, String name, Map<String, Object> fieldNode, Mapper
+        .TypeParser.ParserContext parserContext) {


Seems strange to split the string here rather than moving Mapper.etc to a new line

Agreed. That was a leftover.

dakrone · 2017-01-17T17:55:00Z

core/src/main/java/org/elasticsearch/index/mapper/TypeParsers.java

@@ -117,7 +135,8 @@ private static void parseAnalyzersAndTermVectors(FieldMapper.Builder builder, St
        }

        if (searchAnalyzer == null && searchQuoteAnalyzer != null) {
-            throw new MapperParsingException("analyzer and search_analyzer on field [" + name + "] must be set when search_quote_analyzer is set");
+            throw new MapperParsingException("analyzer and search_analyzer on field [" + name + "] must be set when search_quote_analyzer" +
+                " is set");


Why not break at the existing + next to name instead of adding a new one?

Sure, why not? I've changed it.

…It basically means that no settings should be used before Log4j's status logger has been configured without configuration by LogConfigurator.configureWithoutConfig() method.

Relates elastic/elasticsearch#22200

Make boolean conversion strict

b5d642b

This PR removes all leniency in the conversion of Strings to booleans: "true" is converted to the boolean value `true`, "false" is converted to the boolean value `false`. Everything else raises an error.

danielmitterdorfer added :Core/Infra/Core Core issues without another label >breaking discuss v6.0.0-alpha1 WIP labels Dec 15, 2016

nik9000 reviewed Dec 15, 2016

View reviewed changes

Use Booleans#parseBoolean in JSonXContent

e705d96

tlrx reviewed Dec 16, 2016

View reviewed changes

danielmitterdorfer added 2 commits December 19, 2016 12:59

Merge remote-tracking branch 'origin/master' into strict-booleans

9fb7ea1

Address initial review comments

db3fd5e

danielmitterdorfer removed the discuss label Dec 21, 2016

Merge remote-tracking branch 'origin/master' into strict-booleans

c1b9df1

danielmitterdorfer mentioned this pull request Dec 21, 2016

Cleanup migration code for strict booleans #22298

Closed

danielmitterdorfer added 10 commits December 21, 2016 16:43

Improve BWC

cbb3822

Recognize numbers as booleans in lenient mode

c09b301

Remove boolean leniency for snapshot requests

665554d

Remove boolean leniency for indices options

1ee2db4

Remove boolean leniency for multi search API

f7337ba

Remove boolean leniency for mappers

206adfa

Merge remote-tracking branch 'origin/master' into strict-booleans

fcfce6c

Merge remote-tracking branch 'origin/master' into strict-booleans

8de2eb4

Minor simplifications and more tests

6144f36

Correct minor oddities

22aabf2

danielmitterdorfer added 4 commits January 3, 2017 13:04

Merge remote-tracking branch 'origin/master' into strict-booleans

978f047

Remove IOException in SettingsTests

33af9f1

Avoid to create mixed bool representations in translog

55b7e2b

Merge remote-tracking branch 'origin/master' into strict-booleans

0577acc

nik9000 requested changes Jan 11, 2017

View reviewed changes

danielmitterdorfer added 5 commits January 13, 2017 10:09

Address review comments

4c90110

Merge remote-tracking branch 'origin/master' into strict-booleans

f4a2f64

Include more context on parse errors in nodeBooleanValue

0f91b13

Document breaking REST API changes

61f3912

Correct mapping migration docs

bdc029e

nik9000 approved these changes Jan 17, 2017

View reviewed changes

dakrone approved these changes Jan 17, 2017

View reviewed changes

danielmitterdorfer added 2 commits January 18, 2017 13:39

Merge remote-tracking branch 'origin/master' into strict-booleans

fc8f39a

Address further review comments

4523e55

danielmitterdorfer merged commit aece89d into elastic:master Jan 19, 2017

tlrx mentioned this pull request Jan 19, 2017

Fix status logger message at startup #22687

Closed

jasontedor mentioned this pull request Jan 19, 2017

Fix deprecation logging for lenient booleans #22696

Merged

danielmitterdorfer added a commit to elastic/rally that referenced this pull request Jan 20, 2017

Provide a proper boolean in cluster health call

8f1f10f

Relates elastic/elasticsearch#22200

danielmitterdorfer removed the review label Jan 20, 2017

danielmitterdorfer mentioned this pull request Jan 20, 2017

Deprecate lenient booleans #22716

Merged

javanna mentioned this pull request Mar 21, 2017

Java API: IndicesOptions.lenientExpandOpen() required index names to contain "*" #23557

Closed

p365labs mentioned this pull request Aug 11, 2017

ES6 use strict type on boolean (true|false) ruflin/Elastica#1347

Merged

Grinnz mentioned this pull request Dec 8, 2017

Allow 1 and 0 as booleans? #27733

Closed

javanna mentioned this pull request Mar 16, 2018

_source filtering input validation & behavior #19008

Closed

tmanninger mentioned this pull request Apr 4, 2019

elasticsearch 6 Load more is not working etsy/411#205

Open

jaymode mentioned this pull request Jul 7, 2020

Add Boolean#parseBoolean to forbidden-apis #59190

Open

		@@ -256,7 +257,7 @@ public void addIndexStore(String type, Function<IndexSettings, IndexStore> provi
		* @param name Name of the SimilarityProvider
		* @param similarity SimilarityProvider to register

Make boolean conversion strict #22200

Make boolean conversion strict #22200

Conversation

danielmitterdorfer commented Dec 15, 2016 • edited Loading

jasontedor commented Dec 15, 2016

nik9000 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielmitterdorfer commented Dec 16, 2016

clintongormley commented Dec 16, 2016

Choose a reason for hiding this comment

nik9000 commented Dec 16, 2016

danielmitterdorfer commented Dec 19, 2016

clintongormley commented Dec 19, 2016

danielmitterdorfer commented Jan 10, 2017

nik9000 commented Jan 10, 2017

nik9000 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielmitterdorfer commented Jan 13, 2017

nik9000 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dakrone left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielmitterdorfer commented Dec 15, 2016 •

edited

Loading