SQL: transfer version compatibility decision to the server #53082

bpintea · 2020-03-03T20:47:28Z

This PR transfer the decision to inter-communicate from the clients to the server.
The server will now accept a new request field that conveys the version of the client that originated the request.
For those clients that should have backwards compatibility support (cli, drivers), the server requires that this field be present in query (first/non-paginated) and translate requests.
In this first step, the service policy remains unchanged: the versions need to be in lockstep in order for the server to successfully answer it.

Similarly, the clients still do a server's version validation, but this is just for lower bounding: the server will need to be at least as recent as the client, or newer (plus a concrete lower bound, to prevent connections to older servers missing a version policy).

Closes #52766.

This commit adds a new request object field, "request_version", containing the version of the requesting client. This parameter is now accepted by the server and the request is validated against it. Currently server's and client's versions need to be equal in order for the request to be accepted.

- change 'clientVersion' to 'version' in function names and members; - add testing for the validation of client's version.

Add the new 'client_version' field into the tests. Also: - add the 'client_version' field into proto/SqlClearCursorRequest.java builder. - remove one unused member (ConnectionConfiguration.java:CLIENT_ID).

This commit updates the clients to only check server's version against a lower bound: the server needs to always be on a higher version than the client. The server now enforces the version backwards compatibility. Currently, the versions still need to be in lockstep. Laxing this would be part of future work. The tests are updated to reflect the policy change and to have the version always included in query requests.

- add the version field into the request object of more tests

elasticmachine · 2020-03-03T20:47:30Z

Pinging @elastic/es-search (:Search/SQL)

bpintea · 2020-03-04T07:13:41Z

@elasticmachine update branch

astefan

Left a first set of comments.

astefan · 2020-03-04T09:18:38Z

x-pack/plugin/sql/sql-proto/src/main/java/org/elasticsearch/xpack/sql/proto/Mode.java

@@ -33,4 +33,9 @@ public String toString() {
    public static boolean isDriver(Mode mode) {
        return mode == JDBC || mode == ODBC;
    }
+
+    // TODO: replace all "== Mode.CLI"?
+    public static boolean isCli(Mode mode) {


I don't see the usefulness of this method tbh. Mode is an enum, and there is only one CLI type of mode. Why not keeping the == Mode.CLI? Things are different for isDriver where is a double check, but for CLI why?

In many cases the code look like Mode.isDriver(mode) || mode == Mode.CLI and Mode.isDriver(mode) || Mode.isCli(mode) looked more consistent to me. I got to it from a first thought of adding a Mode.isStrictClient() to check for all drivers+cli (since we treat those grouped in many cases). Irrespective of that, though, if Mode being an enum is to be considered, one would either stick to mode == Mode.JDBC || mode == Mode.jdbc || mode == Mode.CLI or the two methods wrapping, IMO.
However, this isn't a strictly necessary refactoring, it is subjective and I'll happily change it back if you still think the old way is better (just 👍 this comment).

astefan · 2020-03-04T10:08:08Z

x-pack/plugin/sql/sql-cli/src/test/java/org/elasticsearch/xpack/sql/cli/CliSessionTests.java

@@ -26,7 +26,7 @@

    public void testProperConnection() throws Exception {
        HttpClient httpClient = mock(HttpClient.class);
-        when(httpClient.serverInfo()).thenReturn(new MainResponse(randomAlphaOfLength(5), org.elasticsearch.Version.CURRENT.toString(),
+        when(httpClient.serverInfo()).thenReturn(new MainResponse(randomAlphaOfLength(5), Version.CURRENT.toString(),


Why was this changed?

The class has been making use of the client.Version class already. Using two Version versions is not strictly needed anymore. Before this PR client.Version.toString() behaved differently than elasticsearch.Version.toString(), but this has been changed (old behavior is still available in client.Version.versionString(), but that's not used anywhere atm.)

astefan · 2020-03-04T10:16:38Z

x-pack/plugin/sql/sql-cli/src/test/java/org/elasticsearch/xpack/sql/cli/CliSessionTests.java

+                Version.fromString(major + "." + minor + ".23").toString(),
+                ClusterName.DEFAULT.value(), UUIDs.randomBase64UUID()));
+        CliSession cliSession = new CliSession(httpClient);
+        expectThrows(ClientException.class, cliSession::checkConnection);


I think we should check the error message itself, as well.

Sure. Neither of the already defined tests check the message, but I'll look into adding it.

astefan · 2020-03-04T10:58:59Z

x-pack/plugin/sql/sql-proto/src/main/java/org/elasticsearch/xpack/sql/proto/Version.java

+
+
+
+    public static final Version V_7_7_0 = new Version(7, 7, 0);


Maybe call this version something different. For example, in AbstractFieldHitExtractor we have SWITCHED_FROM_DOCVALUES_TO_SOURCE_EXTRACTION. Does it make sense to have this one called ENFORCED_CLIENT_VERSION_PARAMETER?

It could make sense, yes, but I imagine that we'll need to log a new version here with each "breaking" change we add in the protocol. If we'd instrument somehow these changes, referring to the versions by their number might be easier. But we could also refer to the versions by a name that conveys the gist of the breaking change, true. Wdyt?

While I would prefer a name, I think using the versions gives us excellent flexibility in the long term. I'd opt towards adding a comment plus an utility method (that uses the field internally) with a verbose name:

public boolean supportsVersioning(Version version) { return version.compareTo(V_7_...) >= 0; }

s/assertThrows/assertRequestBuilderThrows as per elastic#52582

matriv

Nice stuff! Left some comments.

matriv · 2020-03-04T14:47:16Z

...sql/qa/security/src/test/java/org/elasticsearch/xpack/sql/qa/security/RestSqlSecurityIT.java

                        ContentType.APPLICATION_JSON), mode);

        String cursor = (String) adminResponse.remove("cursor");
        assertNotNull(cursor);

        final String m = randomMode();
        ResponseException e = expectThrows(ResponseException.class, () -> RestActions.runSql("full_access",
-                new StringEntity("{\"cursor\":\"" + cursor + "\"" + mode(m) + "}", ContentType.APPLICATION_JSON), m));
+                new StringEntity("{\"cursor\":\"" + cursor + "\"" + mode(m) + version(mode) + "}", ContentType.APPLICATION_JSON),


should it be version(m) here?

nice catch, thanks. fixed.

matriv · 2020-03-04T14:47:59Z

...n/sql/qa/single-node/src/test/java/org/elasticsearch/xpack/sql/qa/single_node/RestSqlIT.java

@@ -42,16 +42,16 @@ public void testErrorMessageForTranslatingSQLCommandStatement() throws IOExcepti

    public void testErrorMessageForInvalidParamDataType() throws IOException {
        expectBadRequest(() -> runTranslateSql(
-            "{\"query\":\"SELECT null WHERE 0 = ? \", \"mode\": \"odbc\", \"params\":[{\"type\":\"invalid\", \"value\":\"irrelevant\"}]}"
-            ),
+            "{\"query\":\"SELECT null WHERE 0 = ? \", \"mode\": \"odbc\" " + version("odbc") +


maybe mode("odbc") as well (also below)?

makes sense, fixed.

matriv · 2020-03-04T14:52:25Z

...ugin/sql/sql-action/src/main/java/org/elasticsearch/xpack/sql/action/AbstractSqlRequest.java

@@ -56,8 +58,9 @@ public void writeTo(StreamOutput out) throws IOException {
        super.writeTo(out);
        out.writeEnum(requestInfo.mode());
        out.writeOptionalString(requestInfo.clientId());
+        out.writeOptionalString(requestInfo.version() == null ? null : requestInfo.version().toString());


since you use writeOptionalString no need for null check.

the check is there for the .toString() to be safe.

ah yep, I see, thx!

matriv · 2020-03-04T14:53:36Z

.../sql/sql-action/src/test/java/org/elasticsearch/xpack/sql/action/SqlRequestParsersTests.java

                SqlClearCursorRequest::fromXContent);
        assertNull(request.clientId());
+        assertNull(request.version());


Why is it null here?

b/c the parser for SqlClearCursorRequest doesn't set these fields.

matriv · 2020-03-04T14:57:30Z

x-pack/plugin/sql/sql-proto/src/main/java/org/elasticsearch/xpack/sql/proto/Version.java

+    public static final int MINOR_MULTIPLIER = REVISION_MULTIPLIER * REVISION_MULTIPLIER;
+    public static final int MAJOR_MULTIPLIER = REVISION_MULTIPLIER * MINOR_MULTIPLIER;
+
+


nit: please keep one or two empy lines.

sure. (i'm trying not to commit whitespace editor "fixes" - as everybody, prolly - and this one slipped through.)

- add exception message testing; - remove superfluous empty lines; - fix redefinition of mode string;

bpintea · 2020-03-04T16:51:41Z

@elasticmachine update branch

costin

Left a first round of comments.

costin · 2020-03-04T19:22:21Z

...a/multi-node/src/test/java/org/elasticsearch/xpack/sql/qa/multi_node/RestSqlMultinodeIT.java

@@ -110,7 +111,7 @@ private void assertCount(RestClient client, int count) throws IOException {
        expected.put("rows", singletonList(singletonList(count)));

        Request request = new Request("POST", SQL_QUERY_REST_ENDPOINT);
-        request.setJsonEntity("{\"query\": \"SELECT COUNT(*) FROM test\"" + mode(mode) + "}");
+        request.setJsonEntity("{\"query\": \"SELECT COUNT(*) FROM test\"" + mode(mode) + version(mode) + "}");


It's worth adding an utility (or two) to handle the query wrapping:

one to add mode() and version at the end as parameters

another to wrap the given string in a query with the {\"query\", escaped quotes and everything else.

That's true. And the fact that the queries are "manually" build can lead to more work whenever the fields list is updated. I've had a stab at mimicking SqlQueryRequestBuilder's interface at building requests and apply the change through the tests here, but the change is a bit larger, and it might be worth having a separate PR?

costin · 2020-03-04T19:22:46Z

...sql/qa/security/src/test/java/org/elasticsearch/xpack/sql/qa/security/RestSqlSecurityIT.java

@@ -70,10 +71,10 @@ public void expectMatchesAdmin(String adminSql, String user, String userSql) thr
        public void expectScrollMatchesAdmin(String adminSql, String user, String userSql) throws Exception {
            String mode = randomMode();
            Map<String, Object> adminResponse = runSql(null,
-                    new StringEntity("{\"query\": \"" + adminSql + "\", \"fetch_size\": 1" + mode(mode) + "}",
+                    new StringEntity("{\"query\": \"" + adminSql + "\", \"fetch_size\": 1" + mode(mode) + version(mode) + "}",


Same comment as above, it applies in other places but I won't repeat it.

costin · 2020-03-04T19:24:28Z

x-pack/plugin/sql/qa/src/main/java/org/elasticsearch/xpack/sql/qa/SqlProtocolTestCase.java

        if (randomBoolean()) {
            // set it explicitly or leave the default (null) as is
            requestContent = new StringBuilder(requestContent)
                    .insert(requestContent.length() - 1, ",\"binary_format\":" + binaryCommunication).toString();
-            binaryCommunication = ((Mode.isDriver(m) || m == Mode.CLI) && binaryCommunication);
+            binaryCommunication = ((Mode.isDriver(mode) || Mode.isCli(mode)) && binaryCommunication);


Mode.isCli doesn't add much value and since Mode.isDriver() || Mode.isCli is a common pattern, it's worth wrapping that into its own method: Mode.isInternalClient or Mode.isDedicatedClient or Mode.isSqlClient to differentiate between our "own" clients and everything else.

Agreed, fixed it.

costin · 2020-03-04T19:25:02Z

...ck/plugin/sql/qa/src/main/java/org/elasticsearch/xpack/sql/qa/rest/RestSqlUsageTestCase.java

+        Mode mode = Mode.PLAIN;
        if (clientType.equals(ClientType.JDBC.toString())) {
-            mode = Mode.JDBC.toString();
+            mode = Mode.JDBC;
        } else if (clientType.startsWith(ClientType.ODBC.toString())) {
-            mode = Mode.ODBC.toString();
+            mode = Mode.ODBC;
        } else if (clientType.equals(ClientType.CLI.toString())) {
-            mode = Mode.CLI.toString();
+            mode = Mode.CLI;
        }

-        runSql(mode, clientType, sql);
+        runSql(mode.toString(), clientType, sql);


costin · 2020-03-04T19:27:02Z

...sql/sql-action/src/main/java/org/elasticsearch/xpack/sql/action/AbstractSqlQueryRequest.java

@@ -57,6 +63,7 @@
    static final ParseField FILTER = new ParseField("filter");
    static final ParseField MODE = new ParseField("mode");
    static final ParseField CLIENT_ID = new ParseField("client_id");
+    static final ParseField CLIENT_VERSION = new ParseField("client_version");


I would just say version since all parameters are client specific. client_id has is as such since just id would have been too cryptic.
There's no client_mode, or client_params so why client_verision.

In fact, if anything we could change client_id to drop the prefix by using a different word: something like fingerprint or info (too loose).

Makes sense, fixed it.

costin · 2020-03-04T19:33:03Z

...ck/plugin/sql/sql-proto/src/main/java/org/elasticsearch/xpack/sql/proto/SqlQueryRequest.java

@@ -180,6 +180,9 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws
        if (clientId() != null) {
            builder.field("client_id", clientId());
        }
+        if (version() != null) {
+            builder.field("client_version", version().toString());


Some constants for these strings would be nice.

Very much agreed. I would address this in a follow-up PR, thought, since these hardcoded strings are used extensively in tests?

costin · 2020-03-04T19:50:37Z

x-pack/plugin/sql/sql-proto/src/main/java/org/elasticsearch/xpack/sql/proto/Version.java

+
+
+
+    public static final Version V_7_7_0 = new Version(7, 7, 0);


While I would prefer a name, I think using the versions gives us excellent flexibility in the long term. I'd opt towards adding a comment plus an utility method (that uses the field internally) with a verbose name:

public boolean supportsVersioning(Version version) { return version.compareTo(V_7_...) >= 0; }

costin · 2020-03-04T19:52:35Z

x-pack/plugin/sql/sql-client/src/main/java/org/elasticsearch/xpack/sql/client/Version.java

@@ -16,37 +16,20 @@
 import java.util.jar.JarInputStream;
 import java.util.jar.Manifest;

-public class Version {
+public class Version extends org.elasticsearch.xpack.sql.proto.Version {


Functionally, this class is not another Version but a consumer of Version.
It has only isServerCompatible and jdbcMajor/Minor (which were added to this class since it was the only one but could be moved somewhere else).

Try refactoring it to something else either a consumer:

ClientVersion(Version) { .. }
or if there's no state, utility methods - ClientVersion/VersionUtils.isServerCompatible(version)`

Sure. I've turned that class into a ClientVersion utility class.

costin · 2020-03-04T19:56:33Z

x-pack/plugin/sql/sql-client/src/main/java/org/elasticsearch/xpack/sql/client/Version.java

+    // as well.
+    public static boolean isServerCompatible(Version server) {
+        // Starting with this version, the compatibility logic moved from the client to the server. Only relevant for 7.x releases.
+        return server.compareTo(Version.V_7_7_0) >= 0


The V_7_7_0 constant is leaking - encapsulate that into Version (which already has the constant) to something like Version.hasVersionCompatibility/isCompatible or something along those lines so the lines becomes:
return server.isCompatible()

took on your .hasVersionCompatibility() suggestion.

costin · 2020-03-04T19:56:44Z

.../sql/sql-client/src/test/java/org/elasticsearch/xpack/sql/client/HttpClientRequestTests.java

@@ -158,7 +158,7 @@ private void assertBinaryRequestForDrivers(boolean isBinary, XContentType xConte
                null,
                randomBoolean(),
                randomAlphaOfLength(128),
-                new RequestInfo(mode),
+                new RequestInfo(mode, Version.CURRENT),


See my comment on RequestInfo constructor.

- change client.Version to a utility client.ClientVersion class; - rename proto.Version to proto.SqlVersion; - remove double initialization of 'version' in RequestInfo; - make V_7_7_0 version private and expose methods to compare versions against that; - add a Mode.isDedicatedClient(), remove Mode.isCli(); - renamed "client_version" field to just "version".

…asticsearch into feat/add_version_request_field

- VersionTests also updated with new ClientVersion class.

bpintea · 2020-03-06T14:02:31Z

@elasticmachine run elasticsearch-ci/2

The client now only makes sure that server's version is above a certain limit (and not that that version is lower than own).

…quest_field

astefan

Left few more comments.

astefan · 2020-03-07T01:06:05Z

.../plugin/sql/sql-action/src/main/java/org/elasticsearch/xpack/sql/action/SqlQueryRequest.java

@@ -72,7 +72,7 @@ public SqlQueryRequest(String query, List<SqlTypedParamValue> params, QueryBuild

    @Override
    public ActionRequestValidationException validate() {
-        ActionRequestValidationException validationException = null;
+        ActionRequestValidationException validationException = super.validate();


Why wasn't this called here before? The code we had was a bug?

The overridden function (in action/AbstractSqlQueryRequest.java) wasn't implemented before (and now it checks client's version).

astefan · 2020-03-07T01:19:47Z

.../sql/sql-action/src/test/java/org/elasticsearch/xpack/sql/action/SqlRequestParsersTests.java

                + "\"query\":\"select\","
                + "\"params\":[" + params + "],"
                + " \"time_zone\":\"UTC\","
                + "\"request_timeout\":\"5s\",\"page_timeout\":\"10s\"}", SqlQueryRequest::fromXContent);
        assertNull(request.clientId());
        assertEquals(randomMode, request.mode());
+        if (clientVersion.isEmpty() == false) {


Why not using the same condition as above? Mode.isDedicatedClient(randomMode)

good point.

astefan · 2020-03-07T01:32:32Z

x-pack/plugin/sql/src/main/java/org/elasticsearch/xpack/sql/plugin/RestSqlQueryAction.java

@@ -60,7 +60,7 @@ protected RestChannelConsumer prepareRequest(RestRequest request, NodeClient cli
         */
        String accept = null;

-        if ((Mode.isDriver(sqlRequest.requestInfo().mode()) || sqlRequest.requestInfo().mode() == Mode.CLI)
+        if ((Mode.isDedicatedClient(sqlRequest.requestInfo().mode()))


Too many round brackets?

thanks, fixed.

- remove extra brackets - replace condition from string checking to client type checking

bpintea · 2020-03-07T12:27:39Z

@elasticmachine run elasticsearch-ci/2

costin

LGTM

costin · 2020-03-08T21:24:38Z

...ck/plugin/sql/sql-client/src/main/java/org/elasticsearch/xpack/sql/client/ClientVersion.java

-    public static Version fromString(String version) {
-        return new Version(version, "Unknown", from(version));
-    }
+public class ClientVersion {


Worth adding a javadoc to clarify the difference between ClientVersion, SqlVersion and Version.

I've added a short description for SqlVersion and ClientVersion. Hope it's enough, but could elaborate if felt as necessary.

Add short description of the SqlVersion and ClientVersion classes.

fix ref to unavailable org.elasticsearch.Version class

matriv

LGTM

astefan · 2020-03-09T14:08:46Z

x-pack/plugin/sql/sql-cli/src/test/java/org/elasticsearch/xpack/sql/cli/CliSessionTests.java

    public void testConnection() throws Exception {
        HttpClient httpClient = mock(HttpClient.class);
        when(httpClient.serverInfo()).thenThrow(new SQLException("Cannot connect"));
        CliSession cliSession = new CliSession(httpClient);
-        expectThrows(ClientException.class, cliSession::checkConnection);
+        expectThrows(ClientException.class, cliSession::checkConnection, "java.sql.SQLException: Cannot connect");


That's a good way of wrapping two checks in the same one, but throughout the code in SQL (where there are many such checks) we do them separately: expectThrows and then another assertEquals on the exception message.

I'm not saying you should change it, but the way it is now, it is inconsistent throughout sql code.

adjusted to keep consistency.

astefan · 2020-03-09T14:10:23Z

...ck/plugin/sql/sql-client/src/main/java/org/elasticsearch/xpack/sql/client/ClientVersion.java

+/**
+ * Clients-specific version utility class.
+ * <p>
+ *     The class provides the SQL clients the version identifying the release their are part of. The version is read from the encompassing


they're or they are in the sentence identifying the release their are part of.

thanks, fixed.

astefan · 2020-03-09T14:12:12Z

x-pack/plugin/sql/sql-proto/src/main/java/org/elasticsearch/xpack/sql/proto/Mode.java

@@ -33,4 +33,8 @@ public String toString() {
    public static boolean isDriver(Mode mode) {
        return mode == JDBC || mode == ODBC;
    }
+
+    public static boolean isDedicatedClient(Mode mode) {
+        return mode == JDBC || mode == ODBC || mode == CLI;


return isDriver(mode) || mode == CLI

astefan

Left some minor comments still, but LGTM.

- fix spelling - remove two-liner function

…53302) This commit adds a new request object field, "version", containing the version of the requesting client. This parameter is now accepted - and for certain clients required - by the server and the request is validated against it. Currently server's and client's versions still need to be equal in order for the request to be accepted. Relaxing this check is going to be part of future work. On the clients' side, the only check remaining is to ensure that the peer server is supporting version backwards compatibility (i.e. is on, or newer than a certain release). (cherry picked from commit a8f413a)

This param had been removed already along the elastic#53082 work.

* Document VarcharLimit and EarlyExecution params Add the documentation for the newly added VarcharLimit and EarlyExecution DSN attributes. * Remove obsolete VersionChecking param This param had been removed already along the #53082 work. * Update docs/reference/sql/endpoints/odbc/configuration.asciidoc fix typo Co-Authored-By: Stuart Cam <[email protected]> * Update docs/reference/sql/endpoints/odbc/configuration.asciidoc fix typo Co-Authored-By: Stuart Cam <[email protected]>

* Document VarcharLimit and EarlyExecution params Add the documentation for the newly added VarcharLimit and EarlyExecution DSN attributes. * Remove obsolete VersionChecking param This param had been removed already along the #53082 work. * Update docs/reference/sql/endpoints/odbc/configuration.asciidoc fix typo Co-Authored-By: Stuart Cam <[email protected]> * Update docs/reference/sql/endpoints/odbc/configuration.asciidoc fix typo Co-Authored-By: Stuart Cam <[email protected]> (cherry picked from commit f387616)

bpintea added 5 commits February 27, 2020 09:48

refactor 'clientVersion' to 'version'; more tests

3c89600

- change 'clientVersion' to 'version' in function names and members; - add testing for the validation of client's version.

propagate the 'client_version' to more tests

9e8606e

Add the new 'client_version' field into the tests. Also: - add the 'client_version' field into proto/SqlClearCursorRequest.java builder. - remove one unused member (ConnectionConfiguration.java:CLIENT_ID).

further tests fixing

3fffe2b

- add the version field into the request object of more tests

bpintea added :Analytics/SQL SQL querying v8.0.0 v7.7.0 labels Mar 3, 2020

bpintea requested review from costin, astefan and matriv March 3, 2020 20:47

Merge branch 'master' into feat/add_version_request_field

33bcd3d

astefan reviewed Mar 4, 2020

View reviewed changes

update renamed method assertThrows

1058b72

s/assertThrows/assertRequestBuilderThrows as per elastic#52582

matriv reviewed Mar 4, 2020

View reviewed changes

address review notes

c5e1080

- add exception message testing; - remove superfluous empty lines; - fix redefinition of mode string;

Merge branch 'master' into feat/add_version_request_field

e9567b9

costin reviewed Mar 4, 2020

View reviewed changes

bpintea added 3 commits March 6, 2020 12:45

erge branch 'feat/add_version_request_field' of github.com:bpintea/el…

a140656

…asticsearch into feat/add_version_request_field

add change skipped in last commit

a7d1226

- VersionTests also updated with new ClientVersion class.

bpintea added 2 commits March 6, 2020 15:19

adapt u-test to relaxed client-side version checks

d31abeb

The client now only makes sure that server's version is above a certain limit (and not that that version is lower than own).

Merge remote-tracking branch 'origin/master' into feat/add_version_re…

6bcf672

…quest_field

astefan reviewed Mar 7, 2020

View reviewed changes

address review comments

a471c54

- remove extra brackets - replace condition from string checking to client type checking

costin approved these changes Mar 8, 2020

View reviewed changes

bpintea added 2 commits March 9, 2020 10:40

add javadoc on the *Version classes

5926437

Add short description of the SqlVersion and ClientVersion classes.

fix javadoc reference

ee904b3

fix ref to unavailable org.elasticsearch.Version class

matriv approved these changes Mar 9, 2020

View reviewed changes

astefan reviewed Mar 9, 2020

View reviewed changes

astefan approved these changes Mar 9, 2020

View reviewed changes

adress review comments

993113a

- fix spelling - remove two-liner function

bpintea merged commit a8f413a into elastic:master Mar 9, 2020

bpintea deleted the feat/add_version_request_field branch March 9, 2020 18:57

bpintea mentioned this pull request Mar 9, 2020

Prepare the driver to work with newer server releases than its own elastic/elasticsearch-sql-odbc#215

Merged

codebrain mentioned this pull request Apr 1, 2020

7.7.0 meta ticket elastic/elasticsearch-net#4525

Closed

38 tasks

bpintea added a commit to bpintea/elasticsearch that referenced this pull request Apr 2, 2020

Remove obsolete VersionChecking param

f94b4c4

This param had been removed already along the elastic#53082 work.

This was referenced Apr 9, 2020

SQL: Ensure that client responses are serialized based on client's version #29969

Closed

SQL: add request parameter with client's version #47789

Closed

bpintea mentioned this pull request Jun 5, 2020

SQL: add a relevant User-Agent header in all SQL client's requests #52481

Closed

jakelandis added v8.0.0-alpha1 and removed v8.0.0 labels Jul 26, 2021

		public static final int MINOR_MULTIPLIER = REVISION_MULTIPLIER * REVISION_MULTIPLIER;
		public static final int MAJOR_MULTIPLIER = REVISION_MULTIPLIER * MINOR_MULTIPLIER;

SQL: transfer version compatibility decision to the server #53082

SQL: transfer version compatibility decision to the server #53082

Uh oh!

Conversation

bpintea commented Mar 3, 2020

Uh oh!

elasticmachine commented Mar 3, 2020

Uh oh!

bpintea commented Mar 4, 2020

Uh oh!

astefan 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!

matriv 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!

bpintea Mar 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bpintea commented Mar 4, 2020

Uh oh!

costin 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

bpintea Mar 4, 2020 •

edited

Loading