[jira] [Updated] (CALCITE-6280) The Jetty's version number leak occurred while using the avatica http server

2024-02-25 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated CALCITE-6280:

Labels: pull-request-available  (was: )

> The Jetty's version number leak occurred while using the avatica http server
> 
>
> Key: CALCITE-6280
> URL: https://issues.apache.org/jira/browse/CALCITE-6280
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Vaibhav Joshi
>Assignee: Vaibhav Joshi
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Unauthorised access to HTTP server using curl returns the Jerry server 
> version.  See sample response below
> {code:java}
> 
> 
> 
> Error 401 Unauthorized
> 
> HTTP ERROR 401 Unauthorized
> 
> URI:/
> STATUS:401
> MESSAGE:Unauthorized
> SERVLET:-
> 
> https://eclipse.org/jetty;>Powered by Jetty:// 
> 9.4.44.v20210927
> 
>  {code}
>  
> For security reason, it's not advisable to return server version in the 
> response.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CALCITE-6280) The Jetty's version number leak occurred while using the avatica http server

2024-02-25 Thread Vaibhav Joshi (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Joshi updated CALCITE-6280:
---
Summary: The Jetty's version number leak occurred while using the avatica 
http server  (was: The Jetty's version number leak occurred while using the 
query sever)

> The Jetty's version number leak occurred while using the avatica http server
> 
>
> Key: CALCITE-6280
> URL: https://issues.apache.org/jira/browse/CALCITE-6280
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Vaibhav Joshi
>Assignee: Vaibhav Joshi
>Priority: Minor
>
> Unauthorised access to HTTP server using curl returns the Jerry server 
> version.  See sample response below
> {code:java}
> 
> 
> 
> Error 401 Unauthorized
> 
> HTTP ERROR 401 Unauthorized
> 
> URI:/
> STATUS:401
> MESSAGE:Unauthorized
> SERVLET:-
> 
> https://eclipse.org/jetty;>Powered by Jetty:// 
> 9.4.44.v20210927
> 
>  {code}
>  
> For security reason, it's not advisable to return server version in the 
> response.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-6280) The Jetty's version number leak occurred while using the query sever

2024-02-25 Thread Vaibhav Joshi (Jira)
Vaibhav Joshi created CALCITE-6280:
--

 Summary: The Jetty's version number leak occurred while using the 
query sever
 Key: CALCITE-6280
 URL: https://issues.apache.org/jira/browse/CALCITE-6280
 Project: Calcite
  Issue Type: Bug
  Components: avatica
Reporter: Vaibhav Joshi
Assignee: Vaibhav Joshi


Unauthorised access to HTTP server using curl returns the Jerry server version. 
 See sample response below
{code:java}



Error 401 Unauthorized

HTTP ERROR 401 Unauthorized

URI:/
STATUS:401
MESSAGE:Unauthorized
SERVLET:-

https://eclipse.org/jetty;>Powered by Jetty:// 
9.4.44.v20210927

 {code}
 

For security reason, it's not advisable to return server version in the 
response.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (CALCITE-2040) Create adapter for Apache Arrow

2024-02-25 Thread hongyu guo (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

hongyu guo reassigned CALCITE-2040:
---

Assignee: hongyu guo  (was: Julian Hyde)

> 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
> 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] [Comment Edited] (CALCITE-2040) Create adapter for Apache Arrow

2024-02-25 Thread Alessandro Solimando (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820512#comment-17820512
 ] 

Alessandro Solimando edited comment on CALCITE-2040 at 2/25/24 7:33 PM:


[~hongyuguo], I have left a (partial) review, there is enough to be looked at 
already I feel, I will finish the review sometime next week.

Since you are the one currently working on it, it might make sense to assign 
the ticket to yourself and mark it as "in progress", wdyt?


was (Author: asolimando):
[~hongyuguo], I have left a (partial) review, there is enough to be looked at 
already I feel, I will finish the review sometime next week.

> 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.10#820010)


[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow

2024-02-25 Thread Alessandro Solimando (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820512#comment-17820512
 ] 

Alessandro Solimando commented on CALCITE-2040:
---

[~hongyuguo], I have left a (partial) review, there is enough to be looked at 
already I feel, I will finish the review sometime next week.

> 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.10#820010)


[jira] [Comment Edited] (CALCITE-6259) The implementation of the Log library operator does not match the actual dialect behavior.

2024-02-25 Thread Caican Cai (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820483#comment-17820483
 ] 

Caican Cai edited comment on CALCITE-6259 at 2/25/24 2:47 PM:
--

I will output a document for calcite’s math function and analyze the results of 
the math function’s negative test in mysql and postgres. At that time, you can 
evaluate whether we need to modify this part based on this document.


was (Author: JIRAUSER302115):
I will output a document for the math function. At that time, you can evaluate 
whether we need to modify this part based on this.

> The implementation of the Log library operator does not match the actual 
> dialect behavior.
> --
>
> Key: CALCITE-6259
> URL: https://issues.apache.org/jira/browse/CALCITE-6259
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Fix For: 1.37.0
>
> Attachments: 302662660-27b21670-5364-463c-b6dc-d750c46d7cd1.png, 
> 302663876-91173a60-695d-409e-b325-3f91655c6d0d.png
>
>
> The implementation of the Log library operator does not match the actual 
> dialect behavior.
> For example, when log10(0) returns null in mysql and spark, but log10(0) 
> returns error in postgres, neither is calcite's -Intity
> {code:java}
> postgres=# select log10(0);
> ERROR:  cannot take logarithm of zero
> postgres=# select log(2,0);
> ERROR:  cannot take logarithm of zero
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-6259) The implementation of the Log library operator does not match the actual dialect behavior.

2024-02-25 Thread Caican Cai (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820483#comment-17820483
 ] 

Caican Cai commented on CALCITE-6259:
-

I will output a document for the math function. At that time, you can evaluate 
whether we need to modify this part based on this.

> The implementation of the Log library operator does not match the actual 
> dialect behavior.
> --
>
> Key: CALCITE-6259
> URL: https://issues.apache.org/jira/browse/CALCITE-6259
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Fix For: 1.37.0
>
> Attachments: 302662660-27b21670-5364-463c-b6dc-d750c46d7cd1.png, 
> 302663876-91173a60-695d-409e-b325-3f91655c6d0d.png
>
>
> The implementation of the Log library operator does not match the actual 
> dialect behavior.
> For example, when log10(0) returns null in mysql and spark, but log10(0) 
> returns error in postgres, neither is calcite's -Intity
> {code:java}
> postgres=# select log10(0);
> ERROR:  cannot take logarithm of zero
> postgres=# select log(2,0);
> ERROR:  cannot take logarithm of zero
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-6259) The implementation of the Log library operator does not match the actual dialect behavior.

2024-02-25 Thread Caican Cai (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820470#comment-17820470
 ] 

Caican Cai commented on CALCITE-6259:
-

[~mbudiu] [~tanclary] Hi , After testing most of calcite's math functions, I 
found that sqrt, pow and other functions also have similar problems. I don't 
know whether I should continue this jira case. 

ps: Functions like sqrt, pow, and log10 all belong to SqlStdOperatorTable

> The implementation of the Log library operator does not match the actual 
> dialect behavior.
> --
>
> Key: CALCITE-6259
> URL: https://issues.apache.org/jira/browse/CALCITE-6259
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Fix For: 1.37.0
>
> Attachments: 302662660-27b21670-5364-463c-b6dc-d750c46d7cd1.png, 
> 302663876-91173a60-695d-409e-b325-3f91655c6d0d.png
>
>
> The implementation of the Log library operator does not match the actual 
> dialect behavior.
> For example, when log10(0) returns null in mysql and spark, but log10(0) 
> returns error in postgres, neither is calcite's -Intity
> {code:java}
> postgres=# select log10(0);
> ERROR:  cannot take logarithm of zero
> postgres=# select log(2,0);
> ERROR:  cannot take logarithm of zero
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)