[ESQL] Support datetime data type in Least and Greatest functions#113961
Merged
not-napoleon merged 4 commits intoelastic:mainfrom Oct 4, 2024
Merged
[ESQL] Support datetime data type in Least and Greatest functions#113961not-napoleon merged 4 commits intoelastic:mainfrom
not-napoleon merged 4 commits intoelastic:mainfrom
Conversation
Contributor
|
Documentation preview: |
Collaborator
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Collaborator
|
Hi @not-napoleon, I've created a changelog YAML for you. |
Member
Author
|
@elasticmachine update branch |
nik9000
approved these changes
Oct 3, 2024
Member
nik9000
left a comment
There was a problem hiding this comment.
LGTM. I think we're ok not writing another CSV test for this.
I could see a world where we try to build CSV-style tests from our unit test scenarios. But that's for later i think.
Member
You did write a CSV test and I scrolled by. Sorry! |
This was referenced Oct 3, 2024
Closed
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
not-napoleon
added a commit
to not-napoleon/elasticsearch
that referenced
this pull request
Oct 4, 2024
…astic#113961) While working on Date Nanos, I noticed that Least and Greatest didn't have support for datetime. This PR corrects that and adds tests for it. It seems to me that resolveType() is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
not-napoleon
added a commit
to not-napoleon/elasticsearch
that referenced
this pull request
Oct 4, 2024
…astic#113961) While working on Date Nanos, I noticed that Least and Greatest didn't have support for datetime. This PR corrects that and adds tests for it. It seems to me that resolveType() is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Oct 4, 2024
…13961) (#114130) While working on Date Nanos, I noticed that Least and Greatest didn't have support for datetime. This PR corrects that and adds tests for it. It seems to me that resolveType() is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Oct 4, 2024
…13961) (#114138) While working on Date Nanos, I noticed that Least and Greatest didn't have support for datetime. This PR corrects that and adds tests for it. It seems to me that resolveType() is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
matthewabbott
pushed a commit
to matthewabbott/elasticsearch
that referenced
this pull request
Oct 10, 2024
…astic#113961) While working on Date Nanos, I noticed that Least and Greatest didn't have support for datetime. This PR corrects that and adds tests for it. It seems to me that resolveType() is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
not-napoleon
added a commit
that referenced
this pull request
Oct 22, 2024
Resolves #109998 For the most part, this is just adding tests. Greater and Least have actual production code changes - notably toEvaluator is modified to map date nanos to the long evaluator. This parallels the work done in #113961. I've added CSV tests and unit tests for all the functions listed in the original ticket. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
not-napoleon
added a commit
to not-napoleon/elasticsearch
that referenced
this pull request
Oct 22, 2024
…114056) Resolves elastic#109998 For the most part, this is just adding tests. Greater and Least have actual production code changes - notably toEvaluator is modified to map date nanos to the long evaluator. This parallels the work done in elastic#113961. I've added CSV tests and unit tests for all the functions listed in the original ticket. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Oct 24, 2024
…14056) (#115351) * [ESQL] Support date_nanos on functions that take "any" type (#114056) Resolves #109998 For the most part, this is just adding tests. Greater and Least have actual production code changes - notably toEvaluator is modified to map date nanos to the long evaluator. This parallels the work done in #113961. I've added CSV tests and unit tests for all the functions listed in the original ticket. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> * Mute failing watcher test Cherry-pick f8e931d#diff-41386766c394f14f5f205f92bb26eb1420b80af0057c78b2842fcc7ddd3d67aaR326 For whatever reason, git cherry-pick is having some difficulty with this, so I just hand copied the mute. * pull in another mute --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
georgewallace
pushed a commit
to georgewallace/elasticsearch
that referenced
this pull request
Oct 25, 2024
…114056) Resolves elastic#109998 For the most part, this is just adding tests. Greater and Least have actual production code changes - notably toEvaluator is modified to map date nanos to the long evaluator. This parallels the work done in elastic#113961. I've added CSV tests and unit tests for all the functions listed in the original ticket. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
jfreden
pushed a commit
to jfreden/elasticsearch
that referenced
this pull request
Nov 4, 2024
…114056) Resolves elastic#109998 For the most part, this is just adding tests. Greater and Least have actual production code changes - notably toEvaluator is modified to map date nanos to the long evaluator. This parallels the work done in elastic#113961. I've added CSV tests and unit tests for all the functions listed in the original ticket. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While working on Date Nanos, I noticed that Least and Greatest didn't have support for
datetime. This PR corrects that and adds tests for it.It seems to me that
resolveType()is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now.