[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844246#comment-17844246 ] Michael Mior commented on CALCITE-2040: --- Thanks to all who managed to push this over the finish line! > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: hongyu guo >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: arrow_data.py > > Time Spent: 1.5h > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5379) Upgrade protobuf version to 3.21.9 because of CVE
[ https://issues.apache.org/jira/browse/CALCITE-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17633746#comment-17633746 ] Michael Mior commented on CALCITE-5379: --- +1 to what Julian said. Serious vulnerabilities fixed should make the release notes when they are fixed, but otherwise, I would avoid mentioning the vulnerability in most cases. > Upgrade protobuf version to 3.21.9 because of CVE > - > > Key: CALCITE-5379 > URL: https://issues.apache.org/jira/browse/CALCITE-5379 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: avatica-1.22.0 >Reporter: Sergey Nuyanzin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is a CVE in current version > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171 > fixed in 3.21.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17540891#comment-17540891 ] Michael Mior commented on CALCITE-2040: --- [~jswenson] If some simple useful queries work, I think it's fine if several things are broken. What is broken will need to be documented. Having this landed will make it much easier for others to try it out and hopefully also start contributing. If you already have tests written, I would mark them as known failures for now and create tasks to fix them. One of the advantages of having this landed is also that we can make sure all the CI processes are set up to build correctly and that everything continues to build correctly going forward. That in itself has proved to be a big accomplishment. > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: arrow_data.py > > Time Spent: 1.5h > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539613#comment-17539613 ] Michael Mior commented on CALCITE-2040: --- [~jswenson] Thanks for picking this up! I don't think tests failing on M1 is necessarily a blocker. However, it would be nice if we had a way to skip these tests on M1 silicon for now until [ARROW-16608|ARROW-16608] is resolved. > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: arrow_data.py > > Time Spent: 1.5h > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528254#comment-17528254 ] Michael Mior commented on CALCITE-4147: --- For now I've removed this configuration so builds can run, but this could potentially cause an issue at release time. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528240#comment-17528240 ] Michael Mior commented on CALCITE-4147: --- Looking closer, it seems to be a problem with how I'm trying to configure the branch for the stage vote release plugin. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528220#comment-17528220 ] Michael Mior commented on CALCITE-4147: --- [~francischuang] Can you have a look a build failure on GitHub Actions that now appears in both repositories? I'm not sure of the reason for this. https://github.com/apache/calcite/runs/6177612906?check_suite_focus=true > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528219#comment-17528219 ] Michael Mior commented on CALCITE-4147: --- This is done and an email sent to the mailing list with detail. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior closed CALCITE-4147. - Resolution: Fixed > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528151#comment-17528151 ] Michael Mior commented on CALCITE-4147: --- [~francischuang] I opened a ticket with INFRA and I'll push the changes as soon as the branches are renamed. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 2h 50m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528117#comment-17528117 ] Michael Mior edited comment on CALCITE-4147 at 4/26/22 12:01 PM: - [~francischuang] has reviewed the PRs and I think we're good to go ahead. Next step would be to ask INFRA to perform the rename of master branches in the calcite, calcite-site, and calcite-avatica repos. We might want a freeze on pushing to master during this time, although I'm not sure how long it will take INFRA to respond. In any case, when that's done, I'll send more or less the same instructions [~francischuang] sent out previously for calcite-avatica-go and we should be able to move ahead with minimal disruption. was (Author: michaelmior): [~francischuang] has reviewed the PRs and I think we're good to go ahead. Next step would be to ask INFRA to perform the rename of master branches in the calcite, calcite-site, and calcite-avatica repos. We might want a freeze on pushing to master during this time, although I'm not sure how long it will take INFRA to respond. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 2h 50m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528117#comment-17528117 ] Michael Mior commented on CALCITE-4147: --- [~francischuang] has reviewed the PRs and I think we're good to go ahead. Next step would be to ask INFRA to perform the rename of master branches in the calcite, calcite-site, and calcite-avatica repos. We might want a freeze on pushing to master during this time, although I'm not sure how long it will take INFRA to respond. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 2h 50m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526630#comment-17526630 ] Michael Mior commented on CALCITE-4147: --- [~julianhyde] Sounds good. I just rebased both PRs and made a few updates to reflect recent changes. If someone has a chance to look over these, that would be great. As far as process goes, I'd suggest having INFRA do the move, then I would push the changes for Avatica, make sure everything looks good, then do the same for Calcite. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Ask infra to rename the branch on GitHub using Github's renaming tool > (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-5102) Avatica website fails to build
[
https://issues.apache.org/jira/browse/CALCITE-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524931#comment-17524931
]
Michael Mior commented on CALCITE-5102:
---
[~francischuang] Thanks for merging! We could pin to a specific tag but that
just seems likely to have things go stagnant so I'm fine with keeping things
as-is. We probably could set up a GitHub Action to periodically update the
dependencies, but perhaps the effort on that is best saved if and when it
starts to be more of a problem.
> Avatica website fails to build
> --
>
> Key: CALCITE-5102
> URL: https://issues.apache.org/jira/browse/CALCITE-5102
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Minor
> Fix For: avatica-1.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The error below occurs when trying to build the repository via GitHub Actions.
> {noformat}
> Creating network "site_default" with the default driver
> Creating volume "site_gradle-cache" with default driver
> Pulling build-site (jekyll/jekyll:4)...
> 4: Pulling from jekyll/jekyll
> Digest: sha256:5776c8eed572003d9ec021767d725b6aa37226bebf4a5219049c063ff8b698f
> Status: Downloaded newer image for jekyll/jekyll:4
> Creating site_build-site_run ...
> Creating site_build-site_run ... done
> Cloning into '/tmp/calcite-avatica-go'...
> Updated 0 paths from 74ec7ce
> Bundler 2.3.11 is running, but your lockfile was generated with 2.3.10.
> Installing Bundler 2.3.10 and restarting using that version.
> Fetching gem metadata from [https://rubygems.org/.|https://rubygems.org/]
> Fetching bundler 2.3.10
> Installing bundler 2.3.10
> Fetching gem metadata from [https://rubygems.org/.]
> Your bundle is locked to listen (3.1.5) from rubygems repository
> [https://rubygems.org/] or installed locally, but that version can no longer
> be
> found in that source. That means the author of listen (3.1.5) has removed it.
> You'll need to update your bundle to a version other than listen (3.1.5) that
> hasn't been removed in order to install.
> 7
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5102) Avatica website fails to build
[
https://issues.apache.org/jira/browse/CALCITE-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524660#comment-17524660
]
Michael Mior commented on CALCITE-5102:
---
I'm on the fence as far as removing that from the repository, but I lean
towards keeping it. The advantage of removing it is that we will use updated
versions of many dependencies without the need for manual updates. However,
things can still break in the event that a new dependency version has breaking
changes we are somehow not prepared for. In that case, we have no idea what
dependency changed that caused the issue and we have no way to go easily go
back to something that worked unless someone somewhere has a working
environment.
By keeping the lock file, we do risk problems with the Docker environment
updating in a way that is incompatible with these dependencies. However, that
could be fixed by being more strict about the Docker image we're using.
Finally, to be clear, removing the lock file would not have solved this
particular issue since the dependency which is causing the problem was
explicitly pinned to version incompatible with the update to the Docker image.
> Avatica website fails to build
> --
>
> Key: CALCITE-5102
> URL: https://issues.apache.org/jira/browse/CALCITE-5102
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Michael Mior
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The error below occurs when trying to build the repository via GitHub Actions.
> {noformat}
> Creating network "site_default" with the default driver
> Creating volume "site_gradle-cache" with default driver
> Pulling build-site (jekyll/jekyll:4)...
> 4: Pulling from jekyll/jekyll
> Digest: sha256:5776c8eed572003d9ec021767d725b6aa37226bebf4a5219049c063ff8b698f
> Status: Downloaded newer image for jekyll/jekyll:4
> Creating site_build-site_run ...
> Creating site_build-site_run ... done
> Cloning into '/tmp/calcite-avatica-go'...
> Updated 0 paths from 74ec7ce
> Bundler 2.3.11 is running, but your lockfile was generated with 2.3.10.
> Installing Bundler 2.3.10 and restarting using that version.
> Fetching gem metadata from [https://rubygems.org/.|https://rubygems.org/]
> Fetching bundler 2.3.10
> Installing bundler 2.3.10
> Fetching gem metadata from [https://rubygems.org/.]
> Your bundle is locked to listen (3.1.5) from rubygems repository
> [https://rubygems.org/] or installed locally, but that version can no longer
> be
> found in that source. That means the author of listen (3.1.5) has removed it.
> You'll need to update your bundle to a version other than listen (3.1.5) that
> hasn't been removed in order to install.
> 7
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5102) Avatica website fails to build
Michael Mior created CALCITE-5102:
-
Summary: Avatica website fails to build
Key: CALCITE-5102
URL: https://issues.apache.org/jira/browse/CALCITE-5102
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Michael Mior
{{The error below occurs when trying to build the repository via GitHub
Actions.}}
{{ }}
Creating network "site_default" with the default driver
{{Creating volume "site_gradle-cache" with default driver }}
{{Pulling build-site (jekyll/jekyll:4)... }}
{{4: Pulling from jekyll/jekyll }}
{{Digest:
sha256:5776c8eed572003d9ec021767d725b6aa37226bebf4a5219049c063ff8b698ef }}
{{Status: Downloaded newer image for jekyll/jekyll:4 }}
{{Creating site_build-site_run ... }}
{{Creating site_build-site_run ... done }}
{{Cloning into '/tmp/calcite-avatica-go'... }}
{{Updated 0 paths from 74ec7ce }}
{{Bundler 2.3.11 is running, but your lockfile was generated with 2.3.10.
Installing Bundler 2.3.10 and restarting using that version. }}
{{Fetching gem metadata from [https://rubygems.org/.|https://rubygems.org/] }}
{{Fetching bundler 2.3.10 }}
{{Installing bundler 2.3.10 }}
{{Fetching gem metadata from [https://rubygems.org/.] }}
{{Your bundle is locked to listen (3.1.5) from rubygems repository }}
{{[https://rubygems.org/] or installed locally, but that version can no longer
be }}
{{found in that source. That means the author of listen (3.1.5) has removed it.
}}
{{You'll need to update your bundle to a version other than listen (3.1.5) that
}}
{{hasn't been removed in order to install. }}
7
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524470#comment-17524470 ] Michael Mior commented on CALCITE-4147: --- [~julianhyde] Sounds good. [~francischuang], let me know when you have something ready to test. I'm okay with reviving my PR for Calcite and working on that once we have calcite-avatica-go as a proof of concept. One question is how we want to coordinate between Avatica and Calcite. I think perhaps once calcite-avatica-go is migrated, we should try to plan Avatica and Calcite together. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4972) Subfields of array columns containing structs are not qualified in getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481304#comment-17481304
]
Michael Mior commented on CALCITE-4972:
---
This looks good to me, although I'd feel better merging if someone else was
able to do a quick review. Thanks Mark!
> Subfields of array columns containing structs are not qualified in
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value currently is:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-2040: -- Attachment: arrow_data.py > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: arrow_data.py > > Time Spent: 50m > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17320306#comment-17320306 ] Michael Mior commented on CALCITE-2040: --- [^arrow_data.py] > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: arrow_data.py > > Time Spent: 50m > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319642#comment-17319642 ] Michael Mior commented on CALCITE-2040: --- [~julianhyde] Good point. I believe Karshit has a Python script that was used to generate this data file. I'm not sure whether the equivalent APIs exist in Java, but I suppose that's likely that this could be written in Java as well. I'll share a copy of this program as soon as possible. > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17285850#comment-17285850 ] Michael Mior commented on CALCITE-4147: --- [~rubenql] Good to have that here for reference. However, although as far as I am aware, none of those votes were by committers. This doesn't mean that they should be ignored, but there also doesn't seem to be a strong technical justification for not making this change. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17285832#comment-17285832 ] Michael Mior commented on CALCITE-4147: --- [~francischuang] Thanks for reminding me of this. I must have missed the GitHub announcement, but it does look like they have indeed made some changes that will make this easier. I'll work on a draft PR with the necessary code changes for Calcite. We'll need to separately address the site repo and Avatica. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-2040: - Assignee: Michael Mior > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-2173) Sample implementation of ArrowAdapter
[ https://issues.apache.org/jira/browse/CALCITE-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior closed CALCITE-2173. - Resolution: Won't Fix Closing as wontfix since this is no longer being worked on. But there is active effort associated with CALCITE-2040. > Sample implementation of ArrowAdapter > - > > Key: CALCITE-2173 > URL: https://issues.apache.org/jira/browse/CALCITE-2173 > Project: Calcite > Issue Type: Improvement >Reporter: Masayuki Takahashi >Priority: Minor > > I try to implement Apache Arrow adaper. > [https://github.com/masayuki038/calcite/tree/arrow2/arrow/src/main/java/org/apache/calcite/adapter/arrow] > Issues: > * Add ArrowJoin, ArrowUnion, etc.. > * This Arrow Adapter use org.apache.calcite.adapter.enumerable.PhysTypeImpl. > So I have added 'of' method on PhysType to create PhysTypeImpl instance since > it can't access from arrow package. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4355) Improve cost estimates for recursive queries
Michael Mior created CALCITE-4355: - Summary: Improve cost estimates for recursive queries Key: CALCITE-4355 URL: https://issues.apache.org/jira/browse/CALCITE-4355 Project: Calcite Issue Type: Improvement Reporter: Michael Mior I happened to notice [this paper|https://dl.acm.org/doi/abs/10.1145/3340531.3417460] which cites the Calcite paper. They propose improvements on cost estimation over assuming a fixed number of iterative steps which Calcite currently does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3913) Test correctness using formal verification techniques
[ https://issues.apache.org/jira/browse/CALCITE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181352#comment-17181352 ] Michael Mior commented on CALCITE-3913: --- [~qzhou] A pull request certainly makes things easier and separating into multiple commits is helpful. It looks like what you have now would also be better written as a single commit. Also, while I can see why it's helpful for your own use, the current tests in the PR are not necessary since they're really just testing Z3. > Test correctness using formal verification techniques > - > > Key: CALCITE-3913 > URL: https://issues.apache.org/jira/browse/CALCITE-3913 > Project: Calcite > Issue Type: Wish >Reporter: Qi Zhou >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We have developed a technique that can formally be verified if two logical > plans in calcite are indeed semantically equivalent. We published this paper > in VLDB 2019. Here is the [link to the > paper|https://www.vldb.org/pvldb/vol12/p1276-zhou.pdf]. > This technique converts two logical plan into their symbolic representations > and using an SMT (Satisfiability modulo theories) solver to verify the > relationship between two symbolic representations to verify the equivalence. > We are wondering if it is possible that we can integrate this tool into > calcite, as a way to help the correctness testing process in calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3913) Test correctness using formal verification techniques
[ https://issues.apache.org/jira/browse/CALCITE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-3913: -- Flags: (was: Patch) > Test correctness using formal verification techniques > - > > Key: CALCITE-3913 > URL: https://issues.apache.org/jira/browse/CALCITE-3913 > Project: Calcite > Issue Type: Wish >Reporter: Qi Zhou >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We have developed a technique that can formally be verified if two logical > plans in calcite are indeed semantically equivalent. We published this paper > in VLDB 2019. Here is the [link to the > paper|https://www.vldb.org/pvldb/vol12/p1276-zhou.pdf]. > This technique converts two logical plan into their symbolic representations > and using an SMT (Satisfiability modulo theories) solver to verify the > relationship between two symbolic representations to verify the equivalence. > We are wondering if it is possible that we can integrate this tool into > calcite, as a way to help the correctness testing process in calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3913) Test correctness using formal verification techniques
[ https://issues.apache.org/jira/browse/CALCITE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-3913: -- Flags: Patch > Test correctness using formal verification techniques > - > > Key: CALCITE-3913 > URL: https://issues.apache.org/jira/browse/CALCITE-3913 > Project: Calcite > Issue Type: Wish >Reporter: Qi Zhou >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We have developed a technique that can formally be verified if two logical > plans in calcite are indeed semantically equivalent. We published this paper > in VLDB 2019. Here is the [link to the > paper|https://www.vldb.org/pvldb/vol12/p1276-zhou.pdf]. > This technique converts two logical plan into their symbolic representations > and using an SMT (Satisfiability modulo theories) solver to verify the > relationship between two symbolic representations to verify the equivalence. > We are wondering if it is possible that we can integrate this tool into > calcite, as a way to help the correctness testing process in calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3913) Test correctness using formal verification techniques
[ https://issues.apache.org/jira/browse/CALCITE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-3913: -- External issue URL: https://github.com/apache/calcite/pull/2048/ > Test correctness using formal verification techniques > - > > Key: CALCITE-3913 > URL: https://issues.apache.org/jira/browse/CALCITE-3913 > Project: Calcite > Issue Type: Wish >Reporter: Qi Zhou >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We have developed a technique that can formally be verified if two logical > plans in calcite are indeed semantically equivalent. We published this paper > in VLDB 2019. Here is the [link to the > paper|https://www.vldb.org/pvldb/vol12/p1276-zhou.pdf]. > This technique converts two logical plan into their symbolic representations > and using an SMT (Satisfiability modulo theories) solver to verify the > relationship between two symbolic representations to verify the equivalence. > We are wondering if it is possible that we can integrate this tool into > calcite, as a way to help the correctness testing process in calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3913) Test correctness using formal verification techniques
[ https://issues.apache.org/jira/browse/CALCITE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181216#comment-17181216 ] Michael Mior commented on CALCITE-3913: --- [~qzhou] Thanks for starting a pull request! It's good to get started with adding this dependency although I think it would make sense to wait to merge anything until there's some level of integration with Calcite. > Test correctness using formal verification techniques > - > > Key: CALCITE-3913 > URL: https://issues.apache.org/jira/browse/CALCITE-3913 > Project: Calcite > Issue Type: Wish >Reporter: Qi Zhou >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We have developed a technique that can formally be verified if two logical > plans in calcite are indeed semantically equivalent. We published this paper > in VLDB 2019. Here is the [link to the > paper|https://www.vldb.org/pvldb/vol12/p1276-zhou.pdf]. > This technique converts two logical plan into their symbolic representations > and using an SMT (Satisfiability modulo theories) solver to verify the > relationship between two symbolic representations to verify the equivalence. > We are wondering if it is possible that we can integrate this tool into > calcite, as a way to help the correctness testing process in calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-1861) Spatial index, based on Hilbert space-filling curve
[ https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180003#comment-17180003 ] Michael Mior commented on CALCITE-1861: --- [~julianhyde]: What [~txy2539] ended up doing is creating a Postgres UDF based on the same Hilbert code to define a computed column in Postgres with an index so that it could be used for query rewriting. This works pretty well end-to-end although there are a lot of practical concerns to solve with this setup. The UDF was installed manually and the column with the Hilbert value was hardcoded when ideally this would be read from the Postgres catalog. > Spatial index, based on Hilbert space-filling curve > --- > > Key: CALCITE-1861 > URL: https://issues.apache.org/jira/browse/CALCITE-1861 > Project: Calcite > Issue Type: Improvement > Components: spatial >Reporter: Atri Sharma >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Many Calcite users, like Phoenix and Flink can benefit from support of > Spatial indexes. > See: > http://revenant.ca/www/postgis/workshop/indexing.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167862#comment-17167862 ] Michael Mior commented on CALCITE-4147: --- Correct. There will be a clear announcement if this changes. -- -- Michael Mior mm...@apache.org > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167559#comment-17167559 ] Michael Mior commented on CALCITE-4147: --- Thanks [~francischuang] . I also opened up [PR 53|https://github.com/apache/calcite-avatica-go/pull/53] for calcite-avatica-go. However, based on a response from INFRA, it seems like it might be best to temporarily pause on this. GitHub has [announced plans|https://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-] to solve some of the pain points with renaming that should be available later this year. GitHub has recommended waiting until these changes are released, which seems wise. (This includes retargeting open PRs which [~vladimirsitnikov] raised as an important concern.) > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167497#comment-17167497 ] Michael Mior commented on CALCITE-4147: --- [~zabetak] Will do. I expect they just use the default branch so we won't have to do anything, but I'll confirm with INFRA before anything changes. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4147) Rename "master" branch to "main"
[
https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167493#comment-17167493
]
Michael Mior edited comment on CALCITE-4147 at 7/29/20, 8:32 PM:
-
Thanks! Unfortunately it seems the config change I made to set the branch
doesn't actually work. I just added source \{ branch.set("main") } similar to
the example config but this option isn't recognized.
was (Author: michaelmior):
Thanks! Unfortunately it seems the config change I made to set the branch
doesn't actually work. I just added {{source \{ branch.set("main") }}} similar
to the example config but this option isn't recognized.
> Rename "master" branch to "main"
>
>
> Key: CALCITE-4147
> URL: https://issues.apache.org/jira/browse/CALCITE-4147
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
> Settings to change:
> * GIT_COMMIT in [Calcite-Snapshots Jenkins
> pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure]
> * Rename [Calcite-Master Jenkins
> pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure]
> * Default branch on GitHub (open INFRA ticket)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4147) Rename "master" branch to "main"
[
https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167493#comment-17167493
]
Michael Mior edited comment on CALCITE-4147 at 7/29/20, 8:32 PM:
-
Thanks! Unfortunately it seems the config change I made to set the branch
doesn't actually work. I just added {{source \{ branch.set("main") }}} similar
to the example config but this option isn't recognized.
was (Author: michaelmior):
Thanks! Unfortunately it seems the config change I made to set the branch
doesn't actually work. I just added {{source \{ branch.set("main") }}} similar
to the example config but this option isn't recognized.
> Rename "master" branch to "main"
>
>
> Key: CALCITE-4147
> URL: https://issues.apache.org/jira/browse/CALCITE-4147
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
> Settings to change:
> * GIT_COMMIT in [Calcite-Snapshots Jenkins
> pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure]
> * Rename [Calcite-Master Jenkins
> pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure]
> * Default branch on GitHub (open INFRA ticket)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[
https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167493#comment-17167493
]
Michael Mior commented on CALCITE-4147:
---
Thanks! Unfortunately it seems the config change I made to set the branch
doesn't actually work. I just added {{source \{ branch.set("main") }}} similar
to the example config but this option isn't recognized.
> Rename "master" branch to "main"
>
>
> Key: CALCITE-4147
> URL: https://issues.apache.org/jira/browse/CALCITE-4147
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
> Settings to change:
> * GIT_COMMIT in [Calcite-Snapshots Jenkins
> pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure]
> * Rename [Calcite-Master Jenkins
> pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure]
> * Default branch on GitHub (open INFRA ticket)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-4147: -- Description: Settings to change: * GIT_COMMIT in [Calcite-Snapshots Jenkins pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] * Rename [Calcite-Master Jenkins pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] * Default branch on GitHub (open INFRA ticket) was: Settings to change: * GIT_COMMIT in [Calcite-Snapshots Jenkins pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] * Rename [Calcite-Master Jenkins pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > * Default branch on GitHub (open INFRA ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-4147: -- Description: Settings to change: * GIT_COMMIT in [Calcite-Snapshots Jenkins pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] * Rename [Calcite-Master Jenkins pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > > Settings to change: > * GIT_COMMIT in [Calcite-Snapshots Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Snapshots/configure] > * Rename [Calcite-Master Jenkins > pipeline|https://builds.apache.org/view/A-D/view/Calcite/job/Calcite-Master/configure] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167473#comment-17167473 ] Michael Mior commented on CALCITE-4147: --- Opened [PR 2090|https://github.com/apache/calcite/pull/2090] for Calcite and [PR 124|https://github.com/apache/calcite-avatica/pull/124] for Avatica. I think perhaps the first and easiest change is to the site repo. [~francischuang], any potential concerns with this? I'm not sure how the automated builds are configured and if anything needs to be changed there. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4147) Rename "master" branch to "main"
[
https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167347#comment-17167347
]
Michael Mior edited comment on CALCITE-4147 at 7/29/20, 4:44 PM:
-
{quote}It is very important to retarget before master removal.
{quote}
Good to know. On further investigation, it seems like Apache Mahout ended up
with an unexpected mass closing of PRs which we definitely want to avoid.
Although we could just keep master around for a time with pushes disabled. The
downside being that it wouldn't be possible to just press the merge button in
the GitHub web interface but those using the CLI won't experience any extra
friction.
There may also be some minor confusion based on the fact that the master branch
would still exist but I'm not sure that's going to be any more confusing than
having master deleted if people don't pay attention to the announcement of the
change.
was (Author: michaelmior):
{quote}It is very important to retarget before master removal.
{quote}
Good to know. On further investigation, it seems like Apache Mahout ended up
with an unexpected mass closing of PRs which we definitely want to avoid.
Although we could just keep master around for a time with pushes disabled. The
downside being that it wouldn't be possible to just press the merge button in
the GitHub web interface but those using the CLI won't experience any extra
friction.
> Rename "master" branch to "main"
>
>
> Key: CALCITE-4147
> URL: https://issues.apache.org/jira/browse/CALCITE-4147
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[
https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167348#comment-17167348
]
Michael Mior commented on CALCITE-4147:
---
{quote}So extra commands needed to remove master (or initialize with main).
{quote}
I sent a PR which I think resolves this. Although I haven't fully tested since
I'm not entirely sure how to configure the release process to use this
environment.
> Rename "master" branch to "main"
>
>
> Key: CALCITE-4147
> URL: https://issues.apache.org/jira/browse/CALCITE-4147
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[
https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167347#comment-17167347
]
Michael Mior commented on CALCITE-4147:
---
{quote}It is very important to retarget before master removal.
{quote}
Good to know. On further investigation, it seems like Apache Mahout ended up
with an unexpected mass closing of PRs which we definitely want to avoid.
Although we could just keep master around for a time with pushes disabled. The
downside being that it wouldn't be possible to just press the merge button in
the GitHub web interface but those using the CLI won't experience any extra
friction.
> Rename "master" branch to "main"
>
>
> Key: CALCITE-4147
> URL: https://issues.apache.org/jira/browse/CALCITE-4147
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167304#comment-17167304 ] Michael Mior commented on CALCITE-4147: --- Thanks! a) it seems like this is just a [configuration update|https://github.com/michaelmior/calcite/blob/b471f6a8d13f8c10ebf74bb9fcc9a8c02f02693f/build.gradle.kts#L114-L116] (see link for what I believe is the correct change), but good to know b), I know Apache Mahout went through the same thing recently and I believe they were able to have their PRs automatically retargeted, but I've asked for clarification. However, I don't believe PRs would automatically be closed and there's no reason they couldn't be targeted after the fact. The old master ref that the PR is based on would still exist in the history. c) I see no reference to "master" in this repository so it seems like no changes are needed (unless perhaps if there's something we want to test with the new default branch name before actually making the change) > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167271#comment-17167271 ] Michael Mior commented on CALCITE-4147: --- Here's the plan forward as I see it: # Replace all relevant references in documentation and build scripts/configuration with "main" # Audit CI for possible configuration changes external to the code base # Announce the pending change to the mailing list and temporarily freeze commits # Ask INFRA to make main the default branch and disable pushes to master # Ensure main is in sync with mater # Unfreeze commits I've pushed a first pass at these changes in a "main" branch on my fork. What is not currently addressed is Avatica and the calcite-site git repository. [~vlsi] since you did the heavy lifting with the recent Gradle changes, is there anything about the build/release process that you think needs to be changed? AFAICT, there isn't anything aside from documentation updates to ensure releases will be made from the "main" branch, but I want to avoid any unpleasant surprises. > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4147) Rename "master" branch to "main"
[ https://issues.apache.org/jira/browse/CALCITE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-4147: - Assignee: Michael Mior > Rename "master" branch to "main" > > > Key: CALCITE-4147 > URL: https://issues.apache.org/jira/browse/CALCITE-4147 > Project: Calcite > Issue Type: Improvement >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4147) Rename "master" branch to "main"
Michael Mior created CALCITE-4147: - Summary: Rename "master" branch to "main" Key: CALCITE-4147 URL: https://issues.apache.org/jira/browse/CALCITE-4147 Project: Calcite Issue Type: Improvement Reporter: Michael Mior -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4128) Remove dependency of File adapter on Demo CSV adapter
[ https://issues.apache.org/jira/browse/CALCITE-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166484#comment-17166484 ] Michael Mior commented on CALCITE-4128: --- LGTM, and I know a related discussion came up elsewhere, but I wonder if it would make sense to also avoid making the demo CSV adapter dependent on the file adapter. It would have significantly less functionality and would result in some code duplication, but could also serve as a bare bones adapter example. This would be a breaking change since people using the CSV adapter may have to switch to the file adapter to get the same functionality. > Remove dependency of File adapter on Demo CSV adapter > - > > Key: CALCITE-4128 > URL: https://issues.apache.org/jira/browse/CALCITE-4128 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.25.0 > > > Remove dependency of File adapter on Demo CSV adapter. > The dependency should be in the other direction. We want the File adapter to > have lots of capabilities, and the Demo CSV adapter to be easy to understand. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2569) UDFs that are table functions must implement SqlTableFunction and have CURSOR as their return type
[ https://issues.apache.org/jira/browse/CALCITE-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166476#comment-17166476 ] Michael Mior commented on CALCITE-2569: --- [~julianhyde] I think the ANY/IGNORE distinction is potentially confusing but I don't think I have a better suggestion. Also, could you explain the dependency issue referenced in GeoFunctions? Aren't both this and SqlGeoFunctions in core? > UDFs that are table functions must implement SqlTableFunction and have CURSOR > as their return type > -- > > Key: CALCITE-2569 > URL: https://issues.apache.org/jira/browse/CALCITE-2569 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > UDFs that are table functions must implement SqlTableFunction and have CURSOR > as their return type, > Validate that table functions are not used in contexts that require scalar > functions, such as the SELECT clause. > Change operand type ANY to mean 'scalar expression of any type (but not a > cursor)', and add operand type IGNORE to mean skip validation - for an > operand that is not an expression. TABLE is one of the few operators that > accepts a CURSOR operand. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2173) Sample implementation of ArrowAdapter
[ https://issues.apache.org/jira/browse/CALCITE-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155622#comment-17155622 ] Michael Mior commented on CALCITE-2173: --- [~masayuki038] Am I correct that this is no longer actively worked on? I am looking for a student to work with me on something similar and I'd be interested in possibly picking up where you left off. > Sample implementation of ArrowAdapter > - > > Key: CALCITE-2173 > URL: https://issues.apache.org/jira/browse/CALCITE-2173 > Project: Calcite > Issue Type: Improvement >Reporter: Masayuki Takahashi >Priority: Minor > > I try to implement Apache Arrow adaper. > [https://github.com/masayuki038/calcite/tree/arrow2/arrow/src/main/java/org/apache/calcite/adapter/arrow] > Issues: > * Add ArrowJoin, ArrowUnion, etc.. > * This Arrow Adapter use org.apache.calcite.adapter.enumerable.PhysTypeImpl. > So I have added 'of' method on PhysType to create PhysTypeImpl instance since > it can't access from arrow package. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3929) NullPointerException when deserialize UDAF aggregate call from json string
[
https://issues.apache.org/jira/browse/CALCITE-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-3929.
---
Resolution: Fixed
Fixed in
[{{da71139}}|https://github.com/apache/calcite/commit/da7113949d6e22979cbb6981c1992a44db70cd4e]
> NullPointerException when deserialize UDAF aggregate call from json string
> --
>
> Key: CALCITE-3929
> URL: https://issues.apache.org/jira/browse/CALCITE-3929
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When serialize a relation algebra which contains udaf aggregate call, it
> works well and get the json string.
> But when deserialize from the json string, got NullPointerException as below
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:182)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:126)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:144)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:828)
> at
> org.apache.calcite.plan.RelWriterTest.testUDAF(RelWriterTest.java:921)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:43)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:35)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
> at
>
[jira] [Commented] (CALCITE-3907) CassandraSchema ignores username and password if no port is specified
[
https://issues.apache.org/jira/browse/CALCITE-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140657#comment-17140657
]
Michael Mior commented on CALCITE-3907:
---
Fixed in
[{{3e98d75}}|https://github.com/apache/calcite/commit/3e98d75720218715fca0fefe0d5c898d750606ef]
> CassandraSchema ignores username and password if no port is specified
> -
>
> Key: CALCITE-3907
> URL: https://issues.apache.org/jira/browse/CALCITE-3907
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
> Environment: Manjaro Linux with a remote Cassandra
>Reporter: Thomas Heinemann
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The constructor of CassandraSchema which takes username and password
> parameters, but not the port ignores the username and password when
> delegating to the main constructor. Hence, the main constructor tries to
> establish an unauthenticated connection
> h2. Steps to reproduce:
> # Configure a model.json like the following:
> {code:java}
> {
> version: '1.0',
> defaultSchema: 'twissandra',
> schemas: [
> {
> name: 'twissandra',
> type: 'custom',
> factory: 'org.apache.calcite.adapter.cassandra.CassandraSchemaFactory',
> operand: {
> host: 'localhost',
> keyspace: 'twissandra'
> username: 'cassandra'
> password: 'cassandra'
> }
> }
> ]
> }
> {code}
> # Disable unauthenticated connections to the cassandra instance (but make
> sure username and password in the model.json are correct, and that Cassandra
> listens on the default port, i.e. 9042)
> # Use the model.json to connect to your Cassandra instance
> h2. Expected behaviour
> The connection is established using the username and password as given in the
> JSON
> h2. Actual behaviour
> The connection fails, because the connection was tried without using
> authentication
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3907) CassandraSchema ignores username and password if no port is specified
[
https://issues.apache.org/jira/browse/CALCITE-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-3907.
---
Resolution: Fixed
> CassandraSchema ignores username and password if no port is specified
> -
>
> Key: CALCITE-3907
> URL: https://issues.apache.org/jira/browse/CALCITE-3907
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
> Environment: Manjaro Linux with a remote Cassandra
>Reporter: Thomas Heinemann
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The constructor of CassandraSchema which takes username and password
> parameters, but not the port ignores the username and password when
> delegating to the main constructor. Hence, the main constructor tries to
> establish an unauthenticated connection
> h2. Steps to reproduce:
> # Configure a model.json like the following:
> {code:java}
> {
> version: '1.0',
> defaultSchema: 'twissandra',
> schemas: [
> {
> name: 'twissandra',
> type: 'custom',
> factory: 'org.apache.calcite.adapter.cassandra.CassandraSchemaFactory',
> operand: {
> host: 'localhost',
> keyspace: 'twissandra'
> username: 'cassandra'
> password: 'cassandra'
> }
> }
> ]
> }
> {code}
> # Disable unauthenticated connections to the cassandra instance (but make
> sure username and password in the model.json are correct, and that Cassandra
> listens on the default port, i.e. 9042)
> # Use the model.json to connect to your Cassandra instance
> h2. Expected behaviour
> The connection is established using the username and password as given in the
> JSON
> h2. Actual behaviour
> The connection fails, because the connection was tried without using
> authentication
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-1861) Spatial Indexes
[
https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039419#comment-17039419
]
Michael Mior edited comment on CALCITE-1861 at 2/18/20 8:16 PM:
I should also add that if you look in {{site/_docs/spatial.md}}, [~julianhyde]
added a section that gives an example of what such a table definition might
look like. Furthermore, in {{MockCatalogReaderExtended}} you'll see an existing
programmatically-constructed example that is used in tests.
was (Author: michaelmior):
I should also add that if you look in {{site/_docs/spatial.md}}, [~julianhyde]
added a section that gives an example of what such a table definition might
look like.
> Spatial Indexes
> ---
>
> Key: CALCITE-1861
> URL: https://issues.apache.org/jira/browse/CALCITE-1861
> Project: Calcite
> Issue Type: Improvement
> Components: spatial
>Reporter: Atri Sharma
>Priority: Major
>
> Many Calcite users, like Phoenix and Flink can benefit from support of
> Spatial indexes.
> See:
> http://revenant.ca/www/postgis/workshop/indexing.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1861) Spatial Indexes
[
https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039419#comment-17039419
]
Michael Mior commented on CALCITE-1861:
---
I should also add that if you look in {{site/_docs/spatial.md}}, [~julianhyde]
added a section that gives an example of what such a table definition might
look like.
> Spatial Indexes
> ---
>
> Key: CALCITE-1861
> URL: https://issues.apache.org/jira/browse/CALCITE-1861
> Project: Calcite
> Issue Type: Improvement
> Components: spatial
>Reporter: Atri Sharma
>Priority: Major
>
> Many Calcite users, like Phoenix and Flink can benefit from support of
> Spatial indexes.
> See:
> http://revenant.ca/www/postgis/workshop/indexing.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-1861) Spatial Indexes
[
https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039408#comment-17039408
]
Michael Mior edited comment on CALCITE-1861 at 2/18/20 7:58 PM:
[~txy2539] Right now, this is a predicate that is explicitly mentioned in the
query. That is, the rule matches a condition on the query that looks like
{{hilbertColumn = hilbert(latitude, longitude)}}. For testing, you can start
with just creating a table populated with the appropriate values. That is, you
would have the columns {{latitude}}, {{longitude}}, and {{hilbertColumn}} where
the last column contains the pre-computed position on the Hilbert curve. This
could probably be replaced later with a view which defines {{hilbertColumn}} or
as a stored column computed via UDF in the underlying database.
was (Author: michaelmior):
[~txy2539] Right now, this is a predicate that is explicitly mentioned in the
query. That is, the rule matches a condition on the query that looks like
{{hilbertColumn = hilbert(latitude, longitude)}}. For testing, you can start
with just creating a table populated with the appropriate values. That is, you
would have the columns {{latitude}}, {{longitude}}, and {{hilbertColumn}} where
the last column contains the pre-computed position on the Hilbert curve. This
could probably be replaced later with a view which defines {{hilbertColumn}}.
> Spatial Indexes
> ---
>
> Key: CALCITE-1861
> URL: https://issues.apache.org/jira/browse/CALCITE-1861
> Project: Calcite
> Issue Type: Improvement
> Components: spatial
>Reporter: Atri Sharma
>Priority: Major
>
> Many Calcite users, like Phoenix and Flink can benefit from support of
> Spatial indexes.
> See:
> http://revenant.ca/www/postgis/workshop/indexing.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-1861) Spatial Indexes
[
https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039408#comment-17039408
]
Michael Mior edited comment on CALCITE-1861 at 2/18/20 7:52 PM:
[~txy2539] Right now, this is a predicate that is explicitly mentioned in the
query. That is, the rule matches a condition on the query that looks like
{{hilbertColumn = hilbert(latitude, longitude)}}. For testing, you can start
with just creating a table populated with the appropriate values. That is, you
would have the columns {{latitude}}, {{longitude}}, and {{hilbertColumn}} where
the last column contains the pre-computed position on the Hilbert curve. This
could probably be replaced later with a view which defines {{hilbertColumn}}.
was (Author: michaelmior):
[~txy2539] Right now, this is a predicate that is explicitly mentioned in the
query. That is, the rule matches a condition on the query that looks like
`hilbertColumn = hilbert(latitude, longitude)`. For testing, you can start with
just creating a table populated with the appropriate values. That is, you would
have the columns `latitude`, `longitude`, and `hilbertColumn` where the last
column contains the pre-computed position on the Hilbert curve. This could
probably be replaced later with a view which defines `hilbertColumn`.
> Spatial Indexes
> ---
>
> Key: CALCITE-1861
> URL: https://issues.apache.org/jira/browse/CALCITE-1861
> Project: Calcite
> Issue Type: Improvement
> Components: spatial
>Reporter: Atri Sharma
>Priority: Major
>
> Many Calcite users, like Phoenix and Flink can benefit from support of
> Spatial indexes.
> See:
> http://revenant.ca/www/postgis/workshop/indexing.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-1861) Spatial Indexes
[ https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039408#comment-17039408 ] Michael Mior edited comment on CALCITE-1861 at 2/18/20 7:49 PM: [~txy2539] Right now, this is a predicate that is explicitly mentioned in the query. That is, the rule matches a condition on the query that looks like `hilbertColumn = hilbert(latitude, longitude)`. For testing, you can start with just creating a table populated with the appropriate values. That is, you would have the columns `latitude`, `longitude`, and `hilbertColumn` where the last column contains the pre-computed position on the Hilbert curve. This could probably be replaced later with a view which defines `hilbertColumn`. was (Author: michaelmior): [~txy2539] Right now, this is a predicate that is explicitly mentioned in the query. That is, the rule matches a condition on the query that looks like `hilbertColumn = hilbert(latitude, longitude)`. For testing, you can start with just creating a table populated with the appropriate values. That is, you would have the columns `latitude`, `longitude`, and `hilbertColumn` where the last column contains the pre-computed position on the Hilbert curve. > Spatial Indexes > --- > > Key: CALCITE-1861 > URL: https://issues.apache.org/jira/browse/CALCITE-1861 > Project: Calcite > Issue Type: Improvement > Components: spatial >Reporter: Atri Sharma >Priority: Major > > Many Calcite users, like Phoenix and Flink can benefit from support of > Spatial indexes. > See: > http://revenant.ca/www/postgis/workshop/indexing.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-1861) Spatial Indexes
[ https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039408#comment-17039408 ] Michael Mior commented on CALCITE-1861: --- [~txy2539] Right now, this is a predicate that is explicitly mentioned in the query. That is, the rule matches a condition on the query that looks like `hilbertColumn = hilbert(latitude, longitude)`. For testing, you can start with just creating a table populated with the appropriate values. That is, you would have the columns `latitude`, `longitude`, and `hilbertColumn` where the last column contains the pre-computed position on the Hilbert curve. > Spatial Indexes > --- > > Key: CALCITE-1861 > URL: https://issues.apache.org/jira/browse/CALCITE-1861 > Project: Calcite > Issue Type: Improvement > Components: spatial >Reporter: Atri Sharma >Priority: Major > > Many Calcite users, like Phoenix and Flink can benefit from support of > Spatial indexes. > See: > http://revenant.ca/www/postgis/workshop/indexing.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3465) Add support for missing Cassandra 3.x data types
[
https://issues.apache.org/jira/browse/CALCITE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-3465.
---
Resolution: Fixed
Fixed in
{{[5d37a0e|https://github.com/apache/calcite/commit/5d37a0e990a2b84c6616338490d7451065fdd3e5]}}
> Add support for missing Cassandra 3.x data types
>
>
> Key: CALCITE-3465
> URL: https://issues.apache.org/jira/browse/CALCITE-3465
> Project: Calcite
> Issue Type: Improvement
> Components: cassandra-adapter
>Affects Versions: 1.21.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently cassandra-adapter covers only part of the [data types available in
> Cassandra 3.x|[http://cassandra.apache.org/doc/latest/cql/types.html]], the
> scope of the ticket is to extend the coverage and support all data types.
> Current status:
> ||CQL Data Type||SQL Data Type||Java Class||Supported||
> |custom|ANY|N/A|N|
> |duration|ANY|N/A|N|
> |uuid|CHAR|java.lang.String|Y|
> |timeuuid|CHAR|java.lang.String|Y|
> |ascii|VARCHAR|java.lang.String|Y|
> |text|VARCHAR|java.lang.String|Y|
> |varchar|VARCHAR|java.lang.String|Y|
> |int (cint)|INTEGER|int|Y|
> |varint|INTEGER|int|Y|
> |bigint|BIGINT|long|Y|
> |double (cdouble)|DOUBLE|double|Y|
> |float (cfloat)|REAL|float|Y|
> |decimal|DOUBLE|double|Y|
> |blob|VARBINARY|N/A|N|
> |boolean|BOOLEAN|N/A|N|
> |counter|BIGINT|N/A|N|
> |date|DATE|N/A|N|
> |inet|ANY|N/A|N|
> |list|ARRAY|N/A|N|
> |map|MAP|N/A|N|
> |set|MULTISET|N/A|N|
> |smallint|SMALLINT|N/A|N|
> |time|BIGINT|N/A|N|
> |timestamp|TIMESTAMP|N/A|N|
> |tinyint|TINYINT|N/A|N|
> |tuple|STRUCTURED|N/A|N|
> |udt|MAP|N/A|N|
> Second column is derived from
> _org.apache.calcite.adapter.cassandra.CassandraSchema.getRelDataType(...),_
> third column from
> _org.apache.calcite.adapter.cassandra.currentRowField(...)._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2141) Implement query rewrite based on sharding configuration
[
https://issues.apache.org/jira/browse/CALCITE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029957#comment-17029957
]
Michael Mior commented on CALCITE-2141:
---
Just a small heads up that I have a student who's working on something similar
as project during this school term. If anyone has any high-level advice on how
to structure the implementation, that's always appreciated.
> Implement query rewrite based on sharding configuration
> ---
>
> Key: CALCITE-2141
> URL: https://issues.apache.org/jira/browse/CALCITE-2141
> Project: Calcite
> Issue Type: New Feature
>Reporter: Christian Beikov
>Priority: Minor
>
> Based on topology changes, it should be possible to dynamically update a
> sharding configuration for calcite. The effect of such a configuration is,
> that a query involving sharded tables is rewritten to a more optimal form
> possibly targetting mutliple different datasources.
> This is an interesting building block for distributed databases but also for
> applications since it enables the implementation of a static sharding scheme.
> Doing the shard rewriting on a client is also a lot better when using a
> distributed database as that eliminates the need for a coordinator node
> through which data is tunneled.
> Also see [https://github.com/shardingjdbc/sharding-jdbc] for an existing
> implementation.
> So imagine a topology with a master node and 2 worker nodes, one having
> shards with even numbers and the other one having shards with odd numbers.
> Table "A" is sharded by the column "tenant_id" into e.g. 30 shards. So the
> sharding configuration for table "A" would contain the information "worker 1
> has shards 1,3,5,..." and "worker 2 has shards 0,2,4,...". It also specifies
> that the sharding strategy should use a hash function {{shard = tenant_id %
> 30}}.
> When an application sends a query like e.g. {{select * from A where tenant_id
> = 1}}, normally the master/coordinator would do the shard rewriting, but
> doing this already at the client can eliminate the master as bottleneck for
> many scenarios. It is clear that the query can be completely fulfilled by
> worker 1 since it owns shard 1. The query rewriting therefore simply pushes
> the query to that worker. Note that there might be cases where a shard is
> replicated to other workers so it might be beneficial to make it configurable
> whether or when replicas should be used for querying.
> A query like \{{select * from A where tenant_id in(1,2)}} could be
> transformed to {{select * from worker1.A where tenant_id = 1 union all select
> * from worker2.A where tenant_id = 2}}. One optimization could be to target a
> single worker if it contains at least a replica of all required shards, but
> that would need to be configurable again since replicas might lag behind.
>
> DML statements obviously should be handled as well but at first, I would
> simply forbid the use of multiple workers within one transaction. Supporting
> multiple workers in a transaction will essentially require a 2PC and I'm not
> sure it's always a good idea to let an application be the coordinator for
> such a transaction. There should definitely be an option to let a
> master/coordinator node of a distributed database handle the details of the
> 2PC by configuring that DML statements should always be pushed to the
> master/coordinator node.
> The sharding-jdbc implementation only offers _BASE_ guarantees. I guess there
> are cases where this makes sense so making the transaction handling pluggable
> to allow other strategies would definitely be nice as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3707) Implement COSH function
[
https://issues.apache.org/jira/browse/CALCITE-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028201#comment-17028201
]
Michael Mior commented on CALCITE-3707:
---
Fixed in
{{[bcac62e|https://github.com/apache/calcite/commit/bcac62e3dad6137511d4451135daa2d1762ec6ad]}}
> Implement COSH function
> ---
>
> Key: CALCITE-3707
> URL: https://issues.apache.org/jira/browse/CALCITE-3707
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Implement COSH function.
> select cosh(1);
> |EXPR$0|
> |1.543080634815244|
> (1 row)
> !ok
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3707) Implement COSH function
[ https://issues.apache.org/jira/browse/CALCITE-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3707. --- Resolution: Fixed > Implement COSH function > --- > > Key: CALCITE-3707 > URL: https://issues.apache.org/jira/browse/CALCITE-3707 > Project: Calcite > Issue Type: Sub-task >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Implement COSH function. > select cosh(1); > |EXPR$0| > |1.543080634815244| > (1 row) > !ok -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3695) Implement TANH function
[ https://issues.apache.org/jira/browse/CALCITE-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3695. --- Resolution: Fixed > Implement TANH function > --- > > Key: CALCITE-3695 > URL: https://issues.apache.org/jira/browse/CALCITE-3695 > Project: Calcite > Issue Type: Sub-task >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Implement TANH function > select tanh(1); > |EXPR$0| > |0.7615941559557649| > (1 row) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3695) Implement TANH function
[
https://issues.apache.org/jira/browse/CALCITE-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028199#comment-17028199
]
Michael Mior commented on CALCITE-3695:
---
Fixed in
[{{22c70ca}}|https://github.com/apache/calcite/commit/22c70caba8d1942dcde6fcd0039ce71d1525]
> Implement TANH function
> ---
>
> Key: CALCITE-3695
> URL: https://issues.apache.org/jira/browse/CALCITE-3695
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Implement TANH function
> select tanh(1);
> |EXPR$0|
> |0.7615941559557649|
> (1 row)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-1824) GROUP_ID returns wrong result
[
https://issues.apache.org/jira/browse/CALCITE-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-1824.
---
Resolution: Fixed
> GROUP_ID returns wrong result
> -
>
> Key: CALCITE-1824
> URL: https://issues.apache.org/jira/browse/CALCITE-1824
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Julian Hyde
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> We implemented the {{GROUP_ID()}} function in CALCITE-512 but we got the
> specification wrong, and it returns the wrong result.
> {{GROUP_ID}} is not in the SQL standard. It is implemented only by Oracle.
> I mistakenly believed that {{GROUP_ID()}} is equivalent to {{GROUPING_ID(g1,
> ..., gn)}} (in a query with {{GROUP BY g1, ..., gn}}). In fact, {{GROUP_ID}}
> is useful only if you have duplicate grouping sets. If grouping sets are
> distinct, {{GROUP_ID()}} will always return zero.
> Example 1
> {code}SELECT deptno, job, GROUP_ID() AS g
> FROM Emp
> GROUP BY ROLLUP(deptno, job)
> DEPTNO JOB G
> -- - --
> 10 CLERK 0
> 10 MANAGER0
> 10 PRESIDENT 0
> 100
> 20 CLERK 0
> 20 ANALYST0
> 20 MANAGER0
> 200
> 30 CLERK 0
> 30 MANAGER0
> 30 SALESMAN 0
> 300
> 0
> {code} produces grouping sets (deptno, job), (deptno), (). These are
> distinct, so GROUP_ID() is 0 for all rows.
> Example 2
> {code}SELECT deptno, GROUP_ID() AS g
> FROM Emp
> GROUP BY GROUPING SETS (deptno, (), ());
> DEPTNOG
> -- --
> 10 0
> 20 0
> 30 0
> 0
> 1
> {code}
> As you can see, the grouping set () occurs twice. So there is one row in the
> result for each occurrence: the first occurrence has g = 0; the second has g
> = 1.
> In my fix for CALCITE-1069, I will change GROUP_ID() to always return 0. This
> is wrong, but nevertheless closer to the required behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1824) GROUP_ID returns wrong result
[
https://issues.apache.org/jira/browse/CALCITE-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028198#comment-17028198
]
Michael Mior commented on CALCITE-1824:
---
Fixed in
[1eb22d0|https://github.com/apache/calcite/commit/1eb22d03c11b9362b50208261b99eecc3de28fe8].
> GROUP_ID returns wrong result
> -
>
> Key: CALCITE-1824
> URL: https://issues.apache.org/jira/browse/CALCITE-1824
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Julian Hyde
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> We implemented the {{GROUP_ID()}} function in CALCITE-512 but we got the
> specification wrong, and it returns the wrong result.
> {{GROUP_ID}} is not in the SQL standard. It is implemented only by Oracle.
> I mistakenly believed that {{GROUP_ID()}} is equivalent to {{GROUPING_ID(g1,
> ..., gn)}} (in a query with {{GROUP BY g1, ..., gn}}). In fact, {{GROUP_ID}}
> is useful only if you have duplicate grouping sets. If grouping sets are
> distinct, {{GROUP_ID()}} will always return zero.
> Example 1
> {code}SELECT deptno, job, GROUP_ID() AS g
> FROM Emp
> GROUP BY ROLLUP(deptno, job)
> DEPTNO JOB G
> -- - --
> 10 CLERK 0
> 10 MANAGER0
> 10 PRESIDENT 0
> 100
> 20 CLERK 0
> 20 ANALYST0
> 20 MANAGER0
> 200
> 30 CLERK 0
> 30 MANAGER0
> 30 SALESMAN 0
> 300
> 0
> {code} produces grouping sets (deptno, job), (deptno), (). These are
> distinct, so GROUP_ID() is 0 for all rows.
> Example 2
> {code}SELECT deptno, GROUP_ID() AS g
> FROM Emp
> GROUP BY GROUPING SETS (deptno, (), ());
> DEPTNOG
> -- --
> 10 0
> 20 0
> 30 0
> 0
> 1
> {code}
> As you can see, the grouping set () occurs twice. So there is one row in the
> result for each occurrence: the first occurrence has g = 0; the second has g
> = 1.
> In my fix for CALCITE-1069, I will change GROUP_ID() to always return 0. This
> is wrong, but nevertheless closer to the required behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1861) Spatial Indexes
[ https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016354#comment-17016354 ] Michael Mior commented on CALCITE-1861: --- [~julianhyde] I have a student working with me this semester who is hoping to take a first pass at implementing this. In terms of getting some ideas on where to start implementing, I'm assuming the existing lattice code is a good starting point. Do you have any other suggestions? > Spatial Indexes > --- > > Key: CALCITE-1861 > URL: https://issues.apache.org/jira/browse/CALCITE-1861 > Project: Calcite > Issue Type: Improvement > Components: spatial >Reporter: Atri Sharma >Priority: Major > Labels: gsoc2018 > > Many Calcite users, like Phoenix and Flink can benefit from support of > Spatial indexes. > See: > http://revenant.ca/www/postgis/workshop/indexing.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3510) Implement sqlquery for Redis adapter
[
https://issues.apache.org/jira/browse/CALCITE-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16977560#comment-16977560
]
Michael Mior commented on CALCITE-3510:
---
Thanks for the clarification! I didn't read deeply into the code, so I didn't
see how the mapping mechanism was set up. This makes perfect sense to me and I
like the design :)
> Implement sqlquery for Redis adapter
>
>
> Key: CALCITE-3510
> URL: https://issues.apache.org/jira/browse/CALCITE-3510
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The Redis adapter allows querying of live data stored in Redis.Each Redis
> key/value pair is presented as a single row in Presto. Rows can be broken
> down into cells by using table definition files.
> Redis `string` ,`hash`, `sets`, `zsets`, `list` value types are supported;
> CSV format data
> {code:java}
> Set hello_world_1 1, james, 10
> Set hello_world_2 2,bond,20
> Set hello_world_3 3,lily,30
> Set hello_world_4 4,lucy,20
> {code}
> JSON format data
> {code:java}
> Set hello_foo_1 '{"id":1,"name":"james","age":110}'
> Set hello_foo_2 '{"id": 2, "name": "bond", "age": 210}'
> Set hello_foo_3 '{"id": 3, "name": "lily", "age": 310}'
> Set hello_foo_4 '{"id": 3, "name": "lucy", "age": 210}'
> {code}
> RAW format data
> {code:java}
> Set hello_raw_1 1, james, 10
> Set hello_raw_2 2,bond,20
> Set hello_raw_3 3,lily,30
> Set hello_raw_4 4, lucy, 20
> {code}
> We inserted data in three formats, one in CSV format, one in JSON format, and
> one in RAW format. This is the three formats we currently support, which will
> be demonstrated separately.
> Then you can define the corresponding mapping table in the JSON file:
> {code:java}
> {
> "version": "1.0",
> "defaultSchema": "foodmart",
> "schemas": [
> {
> "type": "custom",
> "name": "foodmart",
> "factory": "org.apache.calcite.adapter.redis.RedisSchemaFactory",
> "operand": {
> ```
> "host": "localhost",
> "port": 6379,
> "database": 0,
> "password": ""
> ```
> },
> "tables": [
> {
> "name": "raw_01",
> "factory": "org.apache.calcite.adapter.redis.RedisTableFactory",
> "operand": {
> ```
> "dataFormat": "csv",
> "keyDelimiter": ":",
> "fields": [
> {
> "name": "id",
> "type": "varchar",
> "mapping": "id"
> }
> ```
> ]
> }
> }
> ]
> }
> ]
> }
> {code}
> Here are a few details about the fields:
> keyDelimiter is used to split the value, the default is a colon, and the
> split value is used to map the field column. Only works for the CSV format.
> Format is used to specify the format of the data in Redis. Currently, it
> supports: CSV, JSON and RAW. The raw format keeps the original redis key and
> value intact and only one field key is used for the query. The details are
> not described below.
> The function of COLUMN_MAPPING is to map the columns of Redis to the
> underlying data. Since there is no concept of column under the Redis, the
> specific mapping method varies according to the format. For example, here
> CSV, we know that the CSV data will be formed after being parsed. A string
> array, the corresponding column_mapping is mapped to the index (subscript) of
> the underlying array. For example, here map id to subscript 2, map name to
> subscript 1 and so on.
> You can query the data in the Redis database:
> Mysql> select * from dla_person;
> ||name||id||age||
> |bond|20|2|
> |lily|30|3|
> |lucy|20|4|
> |james|10|1|
> 4 rows in set (0.18 sec)
> Students who are familiar with SQL must feel very cool, you can go to the
> familiar SQL syntax to operate the Redis database.
> JSON
> The above demonstrates the data in CSV format. Let's try the data in JSON
> format. Let's create a new table:
> {code:java}
> {
> "version": "1.0",
> "defaultSchema": "foodmart",
> "schemas": [
> {
> "type": "custom",
> "name": "foodmart",
> "factory": "org.apache.calcite.adapter.redis.RedisSchemaFactory",
> "operand": {
> ```
> "host": "localhost",
> "port": 6379,
> "database": 0,
> "password": ""
> ```
> },
> "tables": [
> {
> "name": "raw_01",
> "factory": "org.apache.calcite.adapter.redis.RedisTableFactory",
> "operand": {
> ```
> "dataFormat": "json",
> "fields": [
> {
> "name": "id",
>
[jira] [Commented] (CALCITE-3510) Implement sqlquery for Redis adapter
[
https://issues.apache.org/jira/browse/CALCITE-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976814#comment-16976814
]
Michael Mior commented on CALCITE-3510:
---
Very cool! Could you clarify exactly what is supported here? Is it only keys
which store list values? What happens with sets, sorted sets, hash sets, etc.?
I'm also not too keen on what seems to be automatic interpretation of the
string value inside the list element. Could you explain how it is decided that
your first example is CSV (but using colons instead of commas), the second is
JSON, and the third is neither?
> Implement sqlquery for Redis adapter
>
>
> Key: CALCITE-3510
> URL: https://issues.apache.org/jira/browse/CALCITE-3510
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 127.0.0.1:6379> LPUSH csv_02 "10:Sales"
> sqlline> select * from "csv_02";
> ||DEPTNO||NAME||
> |20|Sales|
> 127.0.0.1:6379> LPUSH json_02 "{"DEPTNO":10,"NAME":"Sales1"}"
> sqlline> select * from "json_02";
> ||DEPTNO||NAME||
> |20|Sales|
> 127.0.0.1:6379> LPUSH raw_02 "book1"
> sqlline> select * from "raw_02";
> ||key||
> |book1|
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3177) Deserialize from json of + operator cause exception
[ https://issues.apache.org/jira/browse/CALCITE-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900521#comment-16900521 ] Michael Mior commented on CALCITE-3177: --- This one is my fault as I suggested a commit message which follows my preferences, forgetting the recent email thread on the topic. Given the contributor is the one who made the commit, it seemed unnecessary, but it's true it's nice for the changelog. (Although on a related note, I think it would be nicer just to script pulling the name from the commit author.) > Deserialize from json of + operator cause exception > --- > > Key: CALCITE-3177 > URL: https://issues.apache.org/jira/browse/CALCITE-3177 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Attachments: error_info.jpg > > Time Spent: 1h 10m > Remaining Estimate: 0h > > For a simple sql string "select SAL + 10 FROM SALES.EMP", parse it to > RelNode, serialize it to json string works well, but deserialize from the > json string cause exception. The error stack is in the error_info.jpg picture. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (CALCITE-3177) Deserialize from json of + operator cause exception
[ https://issues.apache.org/jira/browse/CALCITE-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3177. --- Resolution: Fixed Fix Version/s: 1.21.0 > Deserialize from json of + operator cause exception > --- > > Key: CALCITE-3177 > URL: https://issues.apache.org/jira/browse/CALCITE-3177 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Attachments: error_info.jpg > > Time Spent: 1h 10m > Remaining Estimate: 0h > > For a simple sql string "select SAL + 10 FROM SALES.EMP", parse it to > RelNode, serialize it to json string works well, but deserialize from the > json string cause exception. The error stack is in the error_info.jpg picture. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3177) Deserialize from json of + operator cause exception
[
https://issues.apache.org/jira/browse/CALCITE-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900049#comment-16900049
]
Michael Mior commented on CALCITE-3177:
---
Fixed in
[{{4954216}}|https://github.com/apache/calcite/commit/4954216c71a6262728ad6ed4792d4ac7b9ec7b71].
> Deserialize from json of + operator cause exception
> ---
>
> Key: CALCITE-3177
> URL: https://issues.apache.org/jira/browse/CALCITE-3177
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Attachments: error_info.jpg
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> For a simple sql string "select SAL + 10 FROM SALES.EMP", parse it to
> RelNode, serialize it to json string works well, but deserialize from the
> json string cause exception. The error stack is in the error_info.jpg picture.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3195) Handle UDF that throws checked exceptions in enumerable code generator
[ https://issues.apache.org/jira/browse/CALCITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3195. --- Resolution: Fixed > Handle UDF that throws checked exceptions in enumerable code generator > -- > > Key: CALCITE-3195 > URL: https://issues.apache.org/jira/browse/CALCITE-3195 > Project: Calcite > Issue Type: Bug > Components: core, piglet >Reporter: Khai Tran >Assignee: Feng Zhu >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Current auto-generated code cannot handle UDFs that throws checked exception, > so the auto-generated code fails to compile. > In piglet, the PigUDFWrapper class is a workaround for handling IOException > from some Pig UDFs. > Need to fix the codegen engine, then remove PigUDFWrapper class. > Related ticket: https://issues.apache.org/jira/browse/CALCITE-3122 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3195) Handle UDF that throws checked exceptions in enumerable code generator
[
https://issues.apache.org/jira/browse/CALCITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891931#comment-16891931
]
Michael Mior commented on CALCITE-3195:
---
Fixed in
[{{18974ce}}|https://github.com/apache/calcite/commit/18974ce8a945424a8a3465c03b253e292641f420].
> Handle UDF that throws checked exceptions in enumerable code generator
> --
>
> Key: CALCITE-3195
> URL: https://issues.apache.org/jira/browse/CALCITE-3195
> Project: Calcite
> Issue Type: Bug
> Components: core, piglet
>Reporter: Khai Tran
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current auto-generated code cannot handle UDFs that throws checked exception,
> so the auto-generated code fails to compile.
> In piglet, the PigUDFWrapper class is a workaround for handling IOException
> from some Pig UDFs.
> Need to fix the codegen engine, then remove PigUDFWrapper class.
> Related ticket: https://issues.apache.org/jira/browse/CALCITE-3122
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3177) Deserialize from json of + operator cause exception
[ https://issues.apache.org/jira/browse/CALCITE-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890995#comment-16890995 ] Michael Mior commented on CALCITE-3177: --- Thanks for the contribution! I left one minor comment on your PR, but overall it looks good. (As a small side note, in the future it's easier to read stack traces if you just paste the text in the issue inside a code block.) > Deserialize from json of + operator cause exception > --- > > Key: CALCITE-3177 > URL: https://issues.apache.org/jira/browse/CALCITE-3177 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > Labels: pull-request-available > Attachments: error_info.jpg > > Time Spent: 20m > Remaining Estimate: 0h > > For a simple sql string "select SAL + 10 FROM SALES.EMP", parse it to > RelNode, serialize it to json string works well, but deserialize from the > json string cause exception. The error stack is in the error_info.jpg picture. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3176) File adapter for parsing JSON files
[
https://issues.apache.org/jira/browse/CALCITE-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889301#comment-16889301
]
Michael Mior commented on CALCITE-3176:
---
Fixed in
[{{ab71c4c}}|https://github.com/apache/calcite/commit/ab71c4cae5a5c3c7d979337a2d38ddaf271aa206].
> File adapter for parsing JSON files
> ---
>
> Key: CALCITE-3176
> URL: https://issues.apache.org/jira/browse/CALCITE-3176
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Michael Mior
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> File adapter for parsing JSON files
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3176) File adapter for parsing JSON files
[ https://issues.apache.org/jira/browse/CALCITE-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3176. --- Resolution: Fixed > File adapter for parsing JSON files > --- > > Key: CALCITE-3176 > URL: https://issues.apache.org/jira/browse/CALCITE-3176 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > File adapter for parsing JSON files -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (CALCITE-3176) File adapter for parsing JSON files
[ https://issues.apache.org/jira/browse/CALCITE-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-3176: - Assignee: Michael Mior (was: Forward Xu) > File adapter for parsing JSON files > --- > > Key: CALCITE-3176 > URL: https://issues.apache.org/jira/browse/CALCITE-3176 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > File adapter for parsing JSON files -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3185) Calcite Web: API doc search does not work (404)
[
https://issues.apache.org/jira/browse/CALCITE-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881303#comment-16881303
]
Michael Mior commented on CALCITE-3185:
---
This seems related to
[JDK-8215291|https://bugs.openjdk.java.net/browse/JDK-8215291] and potentially
fixed by passing the --no-module-directories option when generating the Javadoc.
> Calcite Web: API doc search does not work (404)
> ---
>
> Key: CALCITE-3185
> URL: https://issues.apache.org/jira/browse/CALCITE-3185
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Ruben Quesada Lopez
>Priority: Major
>
> In https://calcite.apache.org/apidocs/ when we type something in the SEARCH
> input, e.g. "RelBuilder", and we click on the corresponding item, we get
> redirected to a wrong url (notice the 'undefined' in the middle):
> https://calcite.apache.org/apidocs/undefined/org/apache/calcite/tools/RelBuilder.html
> which shows the message:
> {code}
> Not Found
> The requested URL /apidocs/undefined/org/apache/calcite/tools/RelBuilder.html
> was not found on this server.
> {code}
> The proper url should be:
> https://calcite.apache.org/apidocs/org/apache/calcite/tools/RelBuilder.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3063) Babel parse should parse PostgreSQL posix regular expressions
[
https://issues.apache.org/jira/browse/CALCITE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-3063.
---
Resolution: Fixed
> Babel parse should parse PostgreSQL posix regular expressions
> -
>
> Key: CALCITE-3063
> URL: https://issues.apache.org/jira/browse/CALCITE-3063
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Quoting from the referenced link below, posix operators are:
> ||Operator||Description||Example||
> |{{~}}|Matches regular expression, case sensitive|{{'thomas' ~ '.*thomas.*'}}|
> |{{~*}}|Matches regular expression, case insensitive|{{'thomas' ~*
> '.*Thomas.*'}}|
> |{{!~}}|Does not match regular expression, case sensitive|{{'thomas' !~
> '.*Thomas.*'}}|
> |{{!~*}}|Does not match regular expression, case insensitive|{{'thomas' !~*
> '.*vadim.*'}}|
>
> +Reference:+
> https://www.postgresql.org/docs/11/functions-matching.html#FUNCTIONS-POSIX-REGEXP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (CALCITE-3063) Babel parse should parse PostgreSQL posix regular expressions
[
https://issues.apache.org/jira/browse/CALCITE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior reopened CALCITE-3063:
---
Issues should not be closed until they have been released. They sit marked as
resolved until then :)
> Babel parse should parse PostgreSQL posix regular expressions
> -
>
> Key: CALCITE-3063
> URL: https://issues.apache.org/jira/browse/CALCITE-3063
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Quoting from the referenced link below, posix operators are:
> ||Operator||Description||Example||
> |{{~}}|Matches regular expression, case sensitive|{{'thomas' ~ '.*thomas.*'}}|
> |{{~*}}|Matches regular expression, case insensitive|{{'thomas' ~*
> '.*Thomas.*'}}|
> |{{!~}}|Does not match regular expression, case sensitive|{{'thomas' !~
> '.*Thomas.*'}}|
> |{{!~*}}|Does not match regular expression, case insensitive|{{'thomas' !~*
> '.*vadim.*'}}|
>
> +Reference:+
> https://www.postgresql.org/docs/11/functions-matching.html#FUNCTIONS-POSIX-REGEXP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3063) Babel parse should parse PostgreSQL posix regular expressions
[
https://issues.apache.org/jira/browse/CALCITE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877187#comment-16877187
]
Michael Mior commented on CALCITE-3063:
---
Fixed in
[{{adf4cc4}}|https://github.com/apache/calcite/commit/adf4cc4dc5cdb9f5e49c85d10f46a2fdcd831ccf].
> Babel parse should parse PostgreSQL posix regular expressions
> -
>
> Key: CALCITE-3063
> URL: https://issues.apache.org/jira/browse/CALCITE-3063
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Quoting from the referenced link below, posix operators are:
> ||Operator||Description||Example||
> |{{~}}|Matches regular expression, case sensitive|{{'thomas' ~ '.*thomas.*'}}|
> |{{~*}}|Matches regular expression, case insensitive|{{'thomas' ~*
> '.*Thomas.*'}}|
> |{{!~}}|Does not match regular expression, case sensitive|{{'thomas' !~
> '.*Thomas.*'}}|
> |{{!~*}}|Does not match regular expression, case insensitive|{{'thomas' !~*
> '.*vadim.*'}}|
>
> +Reference:+
> https://www.postgresql.org/docs/11/functions-matching.html#FUNCTIONS-POSIX-REGEXP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3063) Babel parse should parse PostgreSQL posix regular expressions
[
https://issues.apache.org/jira/browse/CALCITE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-3063.
---
Resolution: Fixed
Fix Version/s: 1.21.0
> Babel parse should parse PostgreSQL posix regular expressions
> -
>
> Key: CALCITE-3063
> URL: https://issues.apache.org/jira/browse/CALCITE-3063
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Quoting from the referenced link below, posix operators are:
> ||Operator||Description||Example||
> |{{~}}|Matches regular expression, case sensitive|{{'thomas' ~ '.*thomas.*'}}|
> |{{~*}}|Matches regular expression, case insensitive|{{'thomas' ~*
> '.*Thomas.*'}}|
> |{{!~}}|Does not match regular expression, case sensitive|{{'thomas' !~
> '.*Thomas.*'}}|
> |{{!~*}}|Does not match regular expression, case insensitive|{{'thomas' !~*
> '.*vadim.*'}}|
>
> +Reference:+
> https://www.postgresql.org/docs/11/functions-matching.html#FUNCTIONS-POSIX-REGEXP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[
https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863301#comment-16863301
]
Michael Mior commented on CALCITE-3119:
---
Fixed in
[{{4e89fdd}}|https://github.com/apache/calcite/commit/4e89fddab415a1e04b82c7d69960e399f608949f].
> Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
> -
>
> Key: CALCITE-3119
> URL: https://issues.apache.org/jira/browse/CALCITE-3119
> Project: Calcite
> Issue Type: Task
>Reporter: Ruben Quesada Lopez
>Assignee: Ruben Quesada Lopez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a
> result, we have right now two enums for (almost) the same purpose:
> CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT,
> SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all
> types of join, mirroring core's JoinRelType).
> The idea is to flag CorrelateJoinType as deprecated, and replace all its
> usages by JoinType.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3119. --- Resolution: Fixed > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 2h > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3127) Support ALTER VIEW Statement
[
https://issues.apache.org/jira/browse/CALCITE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-3127:
--
Fix Version/s: (was: 1.20.0)
> Support ALTER VIEW Statement
>
>
> Key: CALCITE-3127
> URL: https://issues.apache.org/jira/browse/CALCITE-3127
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.19.0
>Reporter: pingle wang
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> support alter view statement :
> {code:java}
> ALTER VIEW name
> [ '(' columnName [, columnName ]* ')' ]
> AS query
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863017#comment-16863017 ] Michael Mior commented on CALCITE-3119: --- Is this ready to be merged? > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861038#comment-16861038 ] Michael Mior commented on CALCITE-3119: --- [~julianhyde] PR looks good to me but do you mind giving it a quick scan? > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858741#comment-16858741
]
Michael Mior commented on CALCITE-2804:
---
Unfortunately, I'm not really a Druid user so I can't say. Any thoughts
[~zhztheplayer]?
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3063) Babel parse should parse PostgreSQL posix regular expressions
[
https://issues.apache.org/jira/browse/CALCITE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-3063:
--
Fix Version/s: (was: 1.20.0)
> Babel parse should parse PostgreSQL posix regular expressions
> -
>
> Key: CALCITE-3063
> URL: https://issues.apache.org/jira/browse/CALCITE-3063
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available,
> pull-requests-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Quoting from the referenced link below, posix operators are:
> ||Operator||Description||Example||
> |{{~}}|Matches regular expression, case sensitive|{{'thomas' ~ '.*thomas.*'}}|
> |{{~*}}|Matches regular expression, case insensitive|{{'thomas' ~*
> '.*Thomas.*'}}|
> |{{!~}}|Does not match regular expression, case sensitive|{{'thomas' !~
> '.*Thomas.*'}}|
> |{{!~*}}|Does not match regular expression, case insensitive|{{'thomas' !~*
> '.*vadim.*'}}|
>
> +Reference:+
> https://www.postgresql.org/docs/11/functions-matching.html#FUNCTIONS-POSIX-REGEXP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1703:
--
Fix Version/s: (was: 1.20.0)
> Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws
> ClassCastException
> ---
>
> Key: CALCITE-1703
> URL: https://issues.apache.org/jira/browse/CALCITE-1703
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
> Environment: Any
>Reporter: Gangadhar Kairi
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Getting below error while executing the query on timestamp columns with
> BETWEEN or AGGREGATE function operator.
> {noformat}
> java.sql.SQLException: Error while executing SQL "select * from "DATE" where
> "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast
> to java.lang.Long
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
> java.lang.Long
> at Baz$1$1.moveNext(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> {noformat}
> I could able to reproduce this issues in CsvTests.
>
> Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '"
> + from + "' and '" + to + "'" you will see test failing with exception.
> Root cause and fix:
> Timestamp datatype needs to be handled in the same way as the Date datatype.
> In {{RexToLixTranslator.convert()}} method and in
> {{PhysTypeImpl.fieldReference()}} method.
--
This message
[jira] [Updated] (CALCITE-2921) nullif(null,y) throws exception in verification
[
https://issues.apache.org/jira/browse/CALCITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-2921:
--
Fix Version/s: (was: 1.20.0)
> nullif(null,y) throws exception in verification
>
>
> Key: CALCITE-2921
> URL: https://issues.apache.org/jira/browse/CALCITE-2921
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently calcite will translate "nullif(x,y)" to a case-when expression,just
> like "case when x = y then null else x".So when "x" is null literal,a
> exception throws out as follow:
> {code:java}
> ELSE clause or at least one THEN clause must be non-NULL
> {code}
> I have test in mysql,"nullif(null,y) works well.So I think we should allow
> this usage of "nullif".
> There are two ways to fix this issue:
> 1) Skip the check for "foundNotNull" in SqlCaseOperator#checkOperandTypes:
>
> {code:java}
> if (!foundNotNull) {
> // according to the sql standard we can not have all of the THEN
> // statements and the ELSE returning null
> if (throwOnFailure) {
> throw callBinding.newError(RESOURCE.mustNotNullInElse());
> }
> return false;
> }{code}
> However, as the comment says, we cannot have all of the THEN and ELSE
> returning null.
> 2) Disable the translation from nullif to case-when and keep "nullif" as it
> is.
> Any suggestion is welcomed,Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2968) New AntiJoin relational expression
[ https://issues.apache.org/jira/browse/CALCITE-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858723#comment-16858723 ] Michael Mior commented on CALCITE-2968: --- Fixed in [be2b979|https://github.com/apache/calcite/commit/be2b97905548a5b24067c8636567b364529332cc] > New AntiJoin relational expression > -- > > Key: CALCITE-2968 > URL: https://issues.apache.org/jira/browse/CALCITE-2968 > Project: Calcite > Issue Type: New Feature >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > The goal of this ticket is to follow the discussion started in CALCITE-2920 > (and its [PR|https://github.com/apache/calcite/pull/1110]). > With the implementation of CALCITE-2920, RelBuilder has now a method to > create an AntiJoin. However, since, for the moment, there is no "AntiJoin" > expression, the only possibility to build an AntiJoin is using a > LogicalCorrelate with SemiJoinType.ANTI, and that's exactly what this method > does, for now. > The idea would be to "generalize" this with the creation of a new AntiJoin > (a.k.a. AntiSemiJoin) relational expression. With the implementation of > CALCITE-2969 (re-design of join-like expressions), it seems clear that the > new AntiJoin expression will be a *LogicalJoin with JoinType=ANTI*. Also, it > will have to be verified that: > - this new AntiJoin works fine in EnumerableConvention with all types of join > condition (equi-join, partial equi-join, non equi-join) > - this new AntiJoin can be correctly transformed into a Correlate (type ANTI) > via JoinToCorrelateRule -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2968) New AntiJoin relational expression
[ https://issues.apache.org/jira/browse/CALCITE-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-2968. --- Resolution: Fixed > New AntiJoin relational expression > -- > > Key: CALCITE-2968 > URL: https://issues.apache.org/jira/browse/CALCITE-2968 > Project: Calcite > Issue Type: New Feature >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > The goal of this ticket is to follow the discussion started in CALCITE-2920 > (and its [PR|https://github.com/apache/calcite/pull/1110]). > With the implementation of CALCITE-2920, RelBuilder has now a method to > create an AntiJoin. However, since, for the moment, there is no "AntiJoin" > expression, the only possibility to build an AntiJoin is using a > LogicalCorrelate with SemiJoinType.ANTI, and that's exactly what this method > does, for now. > The idea would be to "generalize" this with the creation of a new AntiJoin > (a.k.a. AntiSemiJoin) relational expression. With the implementation of > CALCITE-2969 (re-design of join-like expressions), it seems clear that the > new AntiJoin expression will be a *LogicalJoin with JoinType=ANTI*. Also, it > will have to be verified that: > - this new AntiJoin works fine in EnumerableConvention with all types of join > condition (equi-join, partial equi-join, non equi-join) > - this new AntiJoin can be correctly transformed into a Correlate (type ANTI) > via JoinToCorrelateRule -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2736) ReduceExpressionsRule never reduces dynamic expressions but this should be configurable
[ https://issues.apache.org/jira/browse/CALCITE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-2736: -- Fix Version/s: (was: 1.20.0) > ReduceExpressionsRule never reduces dynamic expressions but this should be > configurable > --- > > Key: CALCITE-2736 > URL: https://issues.apache.org/jira/browse/CALCITE-2736 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > There are situations where it is helpful to reduce dynamic SqlCalls. Right > now, the ReduceExpressionsRule always avoids doing this. We should enhance > the rule so this can be configurable depending on where in planning the rule > is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1581) UDTF like in hive
[
https://issues.apache.org/jira/browse/CALCITE-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-1581:
--
Fix Version/s: (was: 1.20.0)
> UDTF like in hive
> -
>
> Key: CALCITE-1581
> URL: https://issues.apache.org/jira/browse/CALCITE-1581
> Project: Calcite
> Issue Type: New Feature
>Reporter: Xiaoyong Deng
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available, udtf
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Support one row in and multi-column/multi-row out(one-to-many mapping), just
> like udtf in hive.
> The query would like this:
> {code}
> select
> func(c0, c1) as (f0, f1, f2)
> from table_name;
> {code}
> c0 and c1 are 'table_name' columns. f0, f1 and f2 are new generated columns.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-2843:
--
Fix Version/s: (was: 1.20.0)
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2764) RelCompositeTrait#satisfies does not work for non-trivial traits
[
https://issues.apache.org/jira/browse/CALCITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-2764:
--
Fix Version/s: (was: 1.20.0)
> RelCompositeTrait#satisfies does not work for non-trivial traits
>
>
> Key: CALCITE-2764
> URL: https://issues.apache.org/jira/browse/CALCITE-2764
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Assignee: Vladimir Sitnikov
>Priority: Major
>
> {noformat}java.lang.AssertionError: [[0, 1], [1]].satisfies([[0, 1], [1]])
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.calcite.plan.RelTraitTest.assertSatisfies(RelTraitTest.java:81)
> at
> org.apache.calcite.plan.RelTraitTest.compositeSatisfies(RelTraitTest.java:77)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
