Replaces the `ExpressionIdGenerator` class with a static method and drops
the `jvmId` field from the `ExpressionId` altogether because it isn't needed.
We still have the potential to roll over expression ids if the server lives for
a long time but it is quite unlikely and rolling over only matters if we roll
over in the same query. So long as each expression id is unique to a
particular query we're fine.
Original commit: elastic/x-pack-elasticsearch@fe3d7f7216
Right now `ProcessorDefinition#resolveAttributes` relies on reference
equality to detect when the rewrite does nothing. At least, all the
nodes rely on this. Maybe this isn't that important, but it is what we
do so we may as well document it.
Original commit: elastic/x-pack-elasticsearch@662372db14
Add support for aliases and indices pattern
Enhance ShowTable info to differentiate between aliases and indices
Add regex filtering of index names
Handle security exceptions (in case of no privileges or no matching)
Original commit: elastic/x-pack-elasticsearch@91e3674ca7
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
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
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
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
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
* SQL: Add support for object/inner/dotted fields
Improve validation when selecting compound fields
Improve fallback to exact field for text fields
Consolidate various field attributes into one
Consolidate various field HitExtractors into one
Improve grammar for column declaration
Update response of embedded server
Improve index validation to allow use of internal indices
Add clean-up of scroll in case of server errors
By default thrown an exception on multi-valued fields
Original commit: elastic/x-pack-elasticsearch@45b73fe0dc
We accidentally stopped returning fields in the same order that the
user asked for them in but some docs tests caught it.
Original commit: elastic/x-pack-elasticsearch@586e3cf207
* SQL: Remove instanceof checks for field retrieval
This removes the `instanceof` checks iterating through the columns determining
what fields need to be retrieved from the ES document. It adds an interface
`FieldExtraction` that collects the fields needed in a builder. The builder can
then build the fields necessary from a `SearchSourceBuilder`.
* Remove default implementation in favor of pushing down exception throwing
Original commit: elastic/x-pack-elasticsearch@11d3d69eb1
Months ago SQL used `Desktop#open` to view the results of graphviz
description of plans. We've since removed this feature in favor of just
writing the file. So now we can build the CLI against the same java
profile that we build everything agianst.
Original commit: elastic/x-pack-elasticsearch@5535f1a6dd
* Starts to build the list of supported functions, adding links to
wikipedia when there is any doubt what the functions mean.
* Extracts an example of using the function from the test suite.
* Explicitly calls out how we round (half up) because there are
lots of ways to round.
Original commit: elastic/x-pack-elasticsearch@5fb64ba869
This adds support for (almost) all of the options that the `query_string` query
supports.
Additionally, it reverts back to the default operator of `OR` rather than `AND`
for the `QUERY()` query.
Relates to elastic/x-pack-elasticsearch#3361
Original commit: elastic/x-pack-elasticsearch@da8b29b53c
* SQL: Add all MATCH() query options
This adds support for (almost) all of the options that the `match` query
supports.
Additionally, it reverts back to the default operator of `OR` rather than `AND`
for the `MATCH()` query.
Relates to elastic/x-pack-elasticsearch#3361
* Add getters required for Node usage
Original commit: elastic/x-pack-elasticsearch@144e2bec02
We don't support the SQL `EXISTS` keyword. It looks like:
```
SELECT * FROM test WHERE EXISTS (SELECT * FROM foo WHERE test.id =
foo.id)
```
It is basically a `JOIN` that doesn't return columns. Since we don't
support `JOIN`, we don't support `EXISTS`.
This PR improves the error message from "unresolved blah blah blah" to
"EXISTS is not yet supported".
relates elastic/x-pack-elasticsearch#3176
Original commit: elastic/x-pack-elasticsearch@548d57c8c1
`SELECT DISTINCT foo FROM bar` is not yet implemented and was returning
an "unplanned item" error which isn't useful to users so I replaced it
with `SELECT DISTINCT is not yet supported`.
`SELECT foo, COUNT(*) FROM bar GROUP BY ALL foo` is not supported.
Specifically the `ALL` part. It is fairly esoteric so see [1] for what
it does. Regardless of what it does it is not widely supported and even
Microsoft's SQL Server has deprecated it so we should never support it.
Probably.
[1]: https://technet.microsoft.com/en-us/library/ms175028(v=sql.90).aspx
Related to elastic/x-pack-elasticsearch#3176
Original commit: elastic/x-pack-elasticsearch@56e5ca3009
`ThreadLocal` variables have a tendency to complicate control flow,
especially if these variables are "context" variables. This PR drops the
`ThreadLocal` that SQL was using for its request context in favor of
delaying construction of the components that need the context until what
they need is ready.
This further simplifies things by passing to components what they need
rather than a larger context object. This is important because not all
of the context is ready at all parts of the request. In particular we
haven't resolved the index until long after the parsing stage, but the
parser wants to know the time zone.
This way of doing things does create a few more objects on each request
but those objects are fairly light and should die as soon as the SQL has
been translated to an Elasticsearch query.
relates elastic/x-pack-elasticsearch#3178
Original commit: elastic/x-pack-elasticsearch@8331f24399
Nik Everett
Costin Leau
Costin Leau
Adrien Grand
Igor Motov
Lee Hinman