The categorization integration tests were picking up a bug in the C++
categorization code, but the expected results were set incorrectly to
match the incorrect C++ output. This change adjusts the expected
results to reflect what is really expected. It also mutes the tests
to avoid failures while the C++ fix propagates through the build
process. The tests will be unmuted tomorrow.
Relates elastic/machine-learning-cpp#512
Original commit: elastic/x-pack-elasticsearch@d2b57b6216
There is an error in the optimizer that causes expressions that look like
`a OR FALSE` to not be rewritten to `a`.
Original commit: elastic/x-pack-elasticsearch@8d19b77b8b
When creating a transport client for a remote index audit trail, we are
implicitly allowing the construction of this transport client to
initialize the number of processors that Netty thinks are on the
system. Since we never pushed down the number of processors, this will
always default to the number of cores on the machine. If the user has
also set the processors setting, when the server bootstraps it will try
to push the number of processors down to Netty too. If this value does
not match the number of cores, we will fail in bootstrap because we
guard against initializing the number of processors that Netty sees to
different values. Instead, the transport client should inherit the
number of processors too and push this down when it pushes the number of
processors down to Netty. We have to worry about another possibility: an
explicit setting for the number of processors for the transport client
so we require this matches the inherited value.
Relates elastic/x-pack-elasticsearch#3469
Original commit: elastic/x-pack-elasticsearch@032810bb0b
Minor refactoring on the reserved realm:
- Removed some duplicated code
- Added in some additional assertions
- Extended some testing
- Removed use of the obsolete "allow_default_passwords" from the test.
Original commit: elastic/x-pack-elasticsearch@584171d2bd
Break lines longer than 140 characters in the planner package to make
them a bit easier to read and make checkstyle happy. It'll make some
merge conflicts but we should be able to deal with them easilly enough.
Original commit: elastic/x-pack-elasticsearch@de8c116f33
Break lines over 140 characters in the expression package to make them a
bit easier to read and to make checkstyle happy.
Original commit: elastic/x-pack-elasticsearch@89487a79cc
Break lines longer than 140 characters in the analyzer package into
multiple lines so they are easier to read and to appease checkstyle.
Original commit: elastic/x-pack-elasticsearch@74c4c6e4ad
Break the lines longer than 140 characters in the querydsl package into
multiple lines to make them easier to read. And to make checkstyle
happy.
Original commit: elastic/x-pack-elasticsearch@cffef88490
SQL's parse tree visitors had some lines longer than 140 characters.
This break them into multiple lines.
Original commit: elastic/x-pack-elasticsearch@58310b02f8
Adds line breaks in long lines in SQL's function package. Rewrites one
line to use `string + string` style instead of `String.format` style
because that is "more normal" in Elasticsearch.
Original commit: elastic/x-pack-elasticsearch@2f4d0358af
Reflows all the text so it wraps around 75 columns for pleasing reading.
And fixes checkstyle errors for the lines that wrap after 140!
Original commit: elastic/x-pack-elasticsearch@9630c8c32e
Replace SQL's blanket suppression of the line length check with targeted
suppressions for each currently violating file.
Original commit: elastic/x-pack-elasticsearch@f96172f4ec
Collapses the interface `FunctionRegistry`, and the classes
`AbstractFunctionRegistry` and `DefaultFunctionRegistry` into a single
class, `FunctionRegistry` and adds some tests for the ctor referencing
behavior inroduced in elastic/x-pack-elasticsearch#3442.
Original commit: elastic/x-pack-elasticsearch@52a697e9b8
* Replaces long line comment with rewritten javadoc with nice line feeds
* Adds some line breaks in a few log lines
Original commit: elastic/x-pack-elasticsearch@00dc7cc9c8
This replaces the marker interfaces and reflection that we once used to
construct functions with method references to constructors. It uses a
few overloaded methods to build the `FunctionDefinition`s from the
method references that adapt the various forms of `Function`
constructors that we have into
`BiFunction<UnresolvedFunction, DateTimeZone, Function>` so that the
compiler can do the complex task of picking the appropriate adapter. It
is good at that sort of thing.
Many of these overloaded functions have `@SuppressWarnings("overloads")`
because they are ambiguous if you wrote one as a lambda without type
parameters. Since we always use constructor references this isn't a
problem.
It does not remove the reflection from function naming or from function
type derivation. This is big enough and these seemed significantly less
fraught.
Original commit: elastic/x-pack-elasticsearch@528d05754b
We test on Windows with the terminal in unix mode, so we need to make sure we send `\n` instead of `\r\n`. In this case the extra `\n` after password was causing an extra new line in tests breaking them on Windows.
Original commit: elastic/x-pack-elasticsearch@721ba32bd6
SQL's `Node` class is a utility for performing tree traversal and
rewrites using reflection. We're not big fans of the reflection part of
that we feel that, where possible, the tree traversal should be done
explicitly.
In this case `Query`'s tree is traversed for three things:
1. To generate the Elasticsearch `QueryBuilder`s. This uses explict tree
traversal and I left it that way.
2. To ehance sorts on nested fields with the filter in the nested field.
I added `enrichNestedSort` to `Query` so each query can implement this
on its own.
3. To add inner hits that are not explicitly mentioned in the query
already when they need to be fetched. I added `containsNestedField` and
`addNestedField` to `Query` to support this.
Note: The nested field code is somewhat dead because we don't support
nested fields at the moment but SQL once did. I've tried to keep it
mostly intact but it is difficult to know for sure if it is still
functioning the same way that it has always functioned.
Original commit: elastic/x-pack-elasticsearch@5d8a8d687a
* SQL: Move shared REST client methods to shared-client
This commit is a preliminary step for moving JDBC to the REST client. It extracts the common REST clients from CLI and moves it to shared-client. This will allow us to move to the 5 project setup: rest-proto, shared-client, server, jdbc, cli with the following dependencies:
server <-- rest-proto
shared-client <-- rest-proto
jdbc <-- shared-client
cli <-- shared-client
Relates to elastic/x-pack-elasticsearch#3419
Original commit: elastic/x-pack-elasticsearch@2e6a134de0
The BWC tests on 6.x need to test both 6.1 and 5.6, so the theory here
is that they just need more memories. This bumps it to ensure the tests
dont OOM.
This bumps it from the previous 1536m, which was already bumped from the
default of 1024m.
Original commit: elastic/x-pack-elasticsearch@cf5700ef47
Switch attribute resolution from tree matching to OO. Adds
`ProcessorDefinition#resolveAttributes` which subclasess implement to
rewrite themselves against a query. `AttributeInput`s use this to
replace themselves with `ReferenceInput`s.
Original commit: elastic/x-pack-elasticsearch@97270d2ea4
Instead of ignoring or throwing an exception, unsupported types are read
If accessed, an error is returned (nicer than the mapping error).
When using * just like with object fields, they are filtered out.
Original commit: elastic/x-pack-elasticsearch@dd244f931c
Switches the "is this query aggs only?" question from pattern matching
on the column tree to an OO-style "ask the columns if they can be aggs
only" method.
I expect this could have been less code if I was willing to define
`supportedByAggsOnlyQuery` as `true` at the top of the
`ProcessorDefinition` object tree and override it only on nodes
`ReferenceInput` and `ScoreProcessorDefinition` but this feels dirty to
me. I tend to think of a superclass as a list of questions that all the
subclasses have to answer rather than a list of behaviors to share.
Pulling the `return true` up saves a few lines of code but breaks my
ability to reason about subclasses.
Original commit: elastic/x-pack-elasticsearch@b1338543cb
It is unsafe to clear passwords of bind requests if the connection is live
and might be used latter (for eg for group searches). This is a temporary
fix that exposes passwords in memory.
Original commit: elastic/x-pack-elasticsearch@e2e1f1a358
David Kyle
David Roberts
Igor Motov
Jason Tedor
Adrien Grand
Ryan Ernst
Nik Everett
Lisa Cawley
Tim Vernum
Alexander Reelsen
Michael Basnight
Costin Leau
Costin Leau
Albert Zaharovits