SQL: add "format" for "full" date range queries #48073
Conversation
set of conditions involving date/datetime literals.
|
Pinging @elastic/es-search (:Search/SQL) |
| @@ -821,9 +823,36 @@ protected QueryTranslation asQuery(Range r, boolean onAggs) { | |||
| if (onAggs) { | |||
| aggFilter = new AggFilter(at.id().toString(), r.asScript()); | |||
| } else { | |||
| Holder<Object> lower = new Holder<>(valueOf(r.lower())); | |||
There was a problem hiding this comment.
Why use the holder? Does the closure require a final variable?
| // no matter the timezone provided by the user | ||
| if (format.get() == null) { | ||
| DateFormatter formatter = null; | ||
| if (lower.get() instanceof ZonedDateTime || upper.get() instanceof ZonedDateTime) { |
There was a problem hiding this comment.
Is there a chance to have different formats between upper and lower? I think so so it might make sense to have two formatters in case of two different formats.
There was a problem hiding this comment.
@costin, I tried to test something that has two different formats (like WHERE date0 > CAST(NOW() - INTERVAL 150 YEARS AS DATE) AND date0 < CAST(NOW() AS DATETIME)) but couldn't do it. If you have any ideas I can try to break this, please let me know.
Also, we need to have one format only because that's the one to be used in the range query. Even if the literals themselves will, in I-don't-know-what-scenario, have two different formats, the range query will need only one. In case the range query will end up having two different formats for from and to there will be a parse_exception error from ES side. So, in either case, range will work with one format only for format, from and to fields (all three need to match).
* elastic/master: [Docs] Fix opType options in IndexRequest API example. (elastic#48290) Simplify Shard Snapshot Upload Code (elastic#48155) Mute ClassificationIT tests (elastic#48338) Reenable azure repository tests and remove some randomization in http servers (elastic#48283) Use an env var for the classpath of jar hell task (elastic#48240) Refactor FIPS BootstrapChecks to simple checks (elastic#47499) Add "format" to "range" queries resulted from optimizing a logical AND (elastic#48073) [DOCS][Transform] document limitation regarding rolling upgrade with 7.2, 7.3 (elastic#48118) Fail with a better error when if there are no ingest nodes (elastic#48272) Fix executing enrich policies stats (elastic#48132) Use MultiFileTransfer in CCR remote recovery (elastic#44514) Make BytesReference an interface (elastic#48171) Also validate source index at put enrich policy time. (elastic#48254) Add 'javadoc' task to lifecycle check tasks (elastic#48214) Remove option to enable direct buffer pooling (elastic#47956) [DOCS] Add 'Selecting gateway and seed nodes' section to CCS docs (elastic#48297) Add Enrich Origin (elastic#48098) fix incorrect comparison (elastic#48208)
In case of a conjunction involving the same date field, the optimizer creates a single
rangequery for that field with bothfromandtopopulated. In the specific case of date literals generated by ES SQL (NOW(), TODAY(), CURRENT_TIMESTAMP() etc) we are enforcing the date format of therangequery so that a potentially custom format for the date field is not used by default by Elasticsearch instead.Similar logic here
Fixes #48033.