Re: [VOTE] Release Apache Calcite Avatica 1.24.0 (release candidate 1)

[Istvan Toth]

+1 (non binding)

Thanks for making the JDK8 build painless.

On Wed, Nov 29, 2023 at 1:21 AM Francis Chuang 
wrote:

> Hi all,
>
> I have created a build for Apache Calcite Avatica 1.24.0, release
> candidate 1.
>
> Thanks to everyone who has contributed to this release.
>
> You can read the release notes here:
>
> https://github.com/apache/calcite-avatica/blob/avatica-1.24.0-rc1/site/_docs/history.md
>
> The commit to be voted upon:
>
> https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=4c0999ba154915eee201bd7a037e223e9368a97d
>
> Its hash is 4c0999ba154915eee201bd7a037e223e9368a97d
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.24.0-rc1
>
> The artifacts to be voted on are located here:
>
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.24.0-rc1
> (revision 65633)
>
> The hashes of the artifacts are as follows:
>
> 41da104d811b3925cbf19452cbe3acac8271bae188efb21f4eed9738dd13b1e353923f63a5ed73aefb05a1d5004211e0d438520b268c9e5d3f3f6c8f98c3be00
> *apache-calcite-avatica-1.24.0-src.tar.gz
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachecalcite-1222/org/apache/calcite/
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/francischuang.asc
> https://www.apache.org/dist/calcite/KEYS
>
> To create the jars and test Apache Calcite Avatica: "gradle build
> -Prelease -PskipSign".
>
> If you do not have a Java/Gradle environment available, you can run the
> tests using docker. To do so, install docker and docker-compose, then
> run "docker-compose run test" from the root of the directory.
>
> Please vote on releasing this package as Apache Calcite Avatica 1.24.0.
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Calcite Avatica 1.24.0
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
>
> Here is my vote:
>
> +1 (binding)
>
> Francis
>


-- 
*István Tóth* | Sr. Staff Software Engineer
*Email*: st...@cloudera.com
cloudera.com 
[image: Cloudera] 
[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 
--
--

[jira] [Created] (CALCITE-6142) Double quote does not work as literal quote string in sql parsing

[peng wu (Jira)]

peng wu created CALCITE-6142:


 Summary: Double quote does not work as literal quote string in sql 
parsing
 Key: CALCITE-6142
 URL: https://issues.apache.org/jira/browse/CALCITE-6142
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.36.0, 1.32.0
 Environment: Here is my test case:
{code:java}
public static void main(String[] args) throws Exception {
String sqlQuery = "case  when `Area` in (   \"Region1\", \"Region2\", 
\"Region3\"  ) then `Sales`  else null end";
//create spark dialect
SqlDialect.Context context = SqlDialect.EMPTY_CONTEXT
.withDatabaseProduct(SqlDialect.DatabaseProduct.SPARK)
.withUnquotedCasing(Casing.UNCHANGED)
.withNullCollation(NullCollation.LOW)
.withIdentifierQuoteString("`")
.withLiteralQuoteString("\"");
SqlDialect sparkDialect = new SparkSqlDialect(context);
SqlParser.Config config = sparkDialect.configureParser(SqlParser.config());
// Create an SQL parser
SqlParser parser = SqlParser.create(sqlQuery, config);
// Parse the query into an AST. Here the exception occurred
SqlNode sqlNode = parser.parseExpression();
  } {code}
Reporter: peng wu


When tried to parse spark sql express where double quote(") as literal quote 
string, calcite sql parser threw an exception: 
org.apache.calcite.sql.parser.impl.ParseException: Encountered "\"" at line 
1, column 26.
Was expecting one of:
    "ABS" ...
    "ARRAY" ...    "AVG" ...
The literal quote string is specified in sql parser config.



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

[VOTE] Release Apache Calcite Avatica 1.24.0 (release candidate 1)

[Francis Chuang]

Hi all,

I have created a build for Apache Calcite Avatica 1.24.0, release
candidate 1.

Thanks to everyone who has contributed to this release.

You can read the release notes here:
https://github.com/apache/calcite-avatica/blob/avatica-1.24.0-rc1/site/_docs/history.md

The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=4c0999ba154915eee201bd7a037e223e9368a97d

Its hash is 4c0999ba154915eee201bd7a037e223e9368a97d

Tag:
https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.24.0-rc1

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.24.0-rc1
(revision 65633)

The hashes of the artifacts are as follows:
41da104d811b3925cbf19452cbe3acac8271bae188efb21f4eed9738dd13b1e353923f63a5ed73aefb05a1d5004211e0d438520b268c9e5d3f3f6c8f98c3be00
*apache-calcite-avatica-1.24.0-src.tar.gz

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1222/org/apache/calcite/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/francischuang.asc
https://www.apache.org/dist/calcite/KEYS

To create the jars and test Apache Calcite Avatica: "gradle build 
-Prelease -PskipSign".


If you do not have a Java/Gradle environment available, you can run the 
tests using docker. To do so, install docker and docker-compose, then 
run "docker-compose run test" from the root of the directory.


Please vote on releasing this package as Apache Calcite Avatica 1.24.0.

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release this package as Apache Calcite Avatica 1.24.0
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...


Here is my vote:

+1 (binding)

Francis

[jira] [Created] (CALCITE-6141) Add a dedicated gradle property for the checkstyle version to be used with jdk8

[Sergey Nuyanzin (Jira)]

Sergey Nuyanzin created CALCITE-6141:


 Summary: Add a dedicated gradle property for the checkstyle 
version to be used with jdk8
 Key: CALCITE-6141
 URL: https://issues.apache.org/jira/browse/CALCITE-6141
 Project: Calcite
  Issue Type: Improvement
  Components: avatica
Affects Versions: avatica-1.23.0
Reporter: Sergey Nuyanzin
Assignee: Sergey Nuyanzin


The issue is that in case of jdk8 in order to compile it with jdk8 there should 
be specified checkstyle version. 
Since current java version could be detected during compilation it could also 
detect which checkstyle version should be used.
This issue was also mentioned in ML  
https://lists.apache.org/thread/r27kdvvhr0222nqlog7xzn5y3yjvz6jp 



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

[CANCEL][VOTE] Release Apache Calcite Avatica 1.24.0 (release candidate 0)

[Francis Chuang]

The vote has been cancelled to address issues building on JDK 8 due to 
incompatible dependencies.


On 28/11/2023 8:32 pm, Istvan Toth wrote:

Francis, The PQS build issue was caused by Avatica including some newer
dependencies (Jackson, IIRC), which include JVM dependent classes. The
current maven-shade-plugin version in PQS cannot handle those JARs, and
needs to be upgraded.
This is a PQS issue, and not  something that Avatica can or should fix.

The JVM 1.8 issue is specific to building Avatica, it doesn't affect
downstream projects that simply depend on the maven binaries.
I only encountered it, because I had to build the RC locally for testing,
and I do not trust the current cross-compile settings in the build.

I have tested Sergey's patch, and it solves the problem, it doesn't look
brittle to me, most related projects have similar workarounds for handling
JVM version differences.

Two different people have hit the JVM 1.8 building issue. Sergey's patch is
a simple fix, which prevents a lot of problems for people trying to build
Avatica in the future. My suggestion is to add it to 1.24.0 .

best regards
Istvan

On Mon, Nov 27, 2023 at 11:38 PM Francis Chuang 
wrote:


PQS already uses Avatica 1.23.0 [1], which already had the change to
upgrade checkstyle (which in turn required a newer version of Java).

I wonder if there's something else causing the issue Istvan is seeing.

[1] https://github.com/apache/phoenix-queryserver/blob/master/pom.xml#L88

On 28/11/2023 9:25 am, Julian Hyde wrote:

Istvan,

You must read the build instructions. If you do not read the build

instructions, you have no basis for voting -1.


Fixing gradle may or may not be the solution. (It might make gradle more

complex and fragile.)


Julian



On Nov 27, 2023, at 2:08 PM, Sergey Nuyanzin 

wrote:


Meanwhile I checked the code

the root cause of the behavior above is upgrade of checkstyle version

from

6.18 to 10.3.2 [1]
which happened in 1.23.0, i.e. it is reproducible with 1.23.0

in this case, please correct me if I'm wrong, this should not be

considered

as a blocker

[1] https://issues.apache.org/jira/browse/CALCITE-5329

On Mon, Nov 27, 2023 at 9:53 PM Sergey Nuyanzin 

wrote:



I created a PR[1]
The main idea is to introduce another property jdk8.checkstyle which is
set to 9.3
before resolving dependency for checkstyle it checks the current java
version. In case of 1.8 it uses new property otherwise the old one
new property also allows to keep ability to change version for jdk8

from

command line in case it is required as "-Pjdk8.checkstyle.version=X.Y"

Also it allows to compile with jdk 8, 11, 17 without explicitly set
checkstyle version

[1] https://github.com/apache/calcite-avatica/pull/233

On Mon, Nov 27, 2023 at 8:05 PM Istvan Toth 


wrote:


Can someone who knows Gradel make a patch to get Gradle to set
-Pcheckstyle.version=9.3 when it detects Java 1.8  ?
This is super simple in Maven with profiles, I expect that it should

not

be
very hard in Gradle either.

Also, I don't think that the exact JVM patch level has anything to do

with

this, as long as it's Java 1.8.

Istvan

On Mon, Nov 27, 2023 at 4:05 PM Guillaume Masse
 wrote:


Hi,

latest jdk 8 is 8u391, 8u371 is two version behind.





https://www.oracle.com/java/technologies/javase/8all-relnotes.html#R8u391-BPR





On Mon, Nov 27, 2023 at 4:21 AM Istvan Toth



wrote:


-1 (non binding)

I have successfully built and run the PQS test suite with the

Avatica

RC

with Java 11.
(I had to tweak the PQS maven setup a bit, but that's not Avatica's

fault)


When I tried to do the same with Java 8, I ran into the issues

mentioned

above.
I was able to hack around the checkstyle/autostyle issue by removing

them

from gradle build files, but then I got:

==
FAILURE: Build failed with an exception.

* Where:
Build file







'/home/stoty/workspaces/apache-phoenix/calcite-avatica/release/build.gradle.kts'

line: 213

* What went wrong:
Task with name 'assemble' not found in project ':release'.
==
and I wasn't able to get any further. (I am no Gradle expert)

Phoenix still supports Java 8, so we need the public artifacts to be

Java 8

compatible.
I imagine Phoenix is not the only project that still supports Java

8.


While Avatica is built with

sourceCompatibility = JavaVersion.VERSION_1_8

targetCompatibility = JavaVersion.VERSION_1_8
It does not seem to set the boot classpath, which does not guarantee

actual

backwards compatibility.
Depending on the Java APIs used, the generated code may or may not

work

on

Java 8 JVMs.

The easy workaround is to use the -release flag instead, but that

doesn't

work on Java 8, so this needs
some hacking of the build system.

best regards
Istvan


On Mon, Nov 27, 2023 at 7:13 AM Benchao Li 

wrote:



Thanks Francis for pointing it out, '-Pcheckstyle.version=9.3'

works

fine.


My vote is +1 (binding).

Francis Chuang  

Re: [VOTE] Release Apache Calcite Avatica 1.24.0 (release candidate 0)

[Francis Chuang]

I am going to cancel this vote and make rc1 available for voting after 
the fix is merged.


On 28/11/2023 8:32 pm, Istvan Toth wrote:

Francis, The PQS build issue was caused by Avatica including some newer
dependencies (Jackson, IIRC), which include JVM dependent classes. The
current maven-shade-plugin version in PQS cannot handle those JARs, and
needs to be upgraded.
This is a PQS issue, and not  something that Avatica can or should fix.

The JVM 1.8 issue is specific to building Avatica, it doesn't affect
downstream projects that simply depend on the maven binaries.
I only encountered it, because I had to build the RC locally for testing,
and I do not trust the current cross-compile settings in the build.

I have tested Sergey's patch, and it solves the problem, it doesn't look
brittle to me, most related projects have similar workarounds for handling
JVM version differences.

Two different people have hit the JVM 1.8 building issue. Sergey's patch is
a simple fix, which prevents a lot of problems for people trying to build
Avatica in the future. My suggestion is to add it to 1.24.0 .

best regards
Istvan

On Mon, Nov 27, 2023 at 11:38 PM Francis Chuang 
wrote:


PQS already uses Avatica 1.23.0 [1], which already had the change to
upgrade checkstyle (which in turn required a newer version of Java).

I wonder if there's something else causing the issue Istvan is seeing.

[1] https://github.com/apache/phoenix-queryserver/blob/master/pom.xml#L88

On 28/11/2023 9:25 am, Julian Hyde wrote:

Istvan,

You must read the build instructions. If you do not read the build

instructions, you have no basis for voting -1.


Fixing gradle may or may not be the solution. (It might make gradle more

complex and fragile.)


Julian



On Nov 27, 2023, at 2:08 PM, Sergey Nuyanzin 

wrote:


Meanwhile I checked the code

the root cause of the behavior above is upgrade of checkstyle version

from

6.18 to 10.3.2 [1]
which happened in 1.23.0, i.e. it is reproducible with 1.23.0

in this case, please correct me if I'm wrong, this should not be

considered

as a blocker

[1] https://issues.apache.org/jira/browse/CALCITE-5329

On Mon, Nov 27, 2023 at 9:53 PM Sergey Nuyanzin 

wrote:



I created a PR[1]
The main idea is to introduce another property jdk8.checkstyle which is
set to 9.3
before resolving dependency for checkstyle it checks the current java
version. In case of 1.8 it uses new property otherwise the old one
new property also allows to keep ability to change version for jdk8

from

command line in case it is required as "-Pjdk8.checkstyle.version=X.Y"

Also it allows to compile with jdk 8, 11, 17 without explicitly set
checkstyle version

[1] https://github.com/apache/calcite-avatica/pull/233

On Mon, Nov 27, 2023 at 8:05 PM Istvan Toth 


wrote:


Can someone who knows Gradel make a patch to get Gradle to set
-Pcheckstyle.version=9.3 when it detects Java 1.8  ?
This is super simple in Maven with profiles, I expect that it should

not

be
very hard in Gradle either.

Also, I don't think that the exact JVM patch level has anything to do

with

this, as long as it's Java 1.8.

Istvan

On Mon, Nov 27, 2023 at 4:05 PM Guillaume Masse
 wrote:


Hi,

latest jdk 8 is 8u391, 8u371 is two version behind.





https://www.oracle.com/java/technologies/javase/8all-relnotes.html#R8u391-BPR





On Mon, Nov 27, 2023 at 4:21 AM Istvan Toth



wrote:


-1 (non binding)

I have successfully built and run the PQS test suite with the

Avatica

RC

with Java 11.
(I had to tweak the PQS maven setup a bit, but that's not Avatica's

fault)


When I tried to do the same with Java 8, I ran into the issues

mentioned

above.
I was able to hack around the checkstyle/autostyle issue by removing

them

from gradle build files, but then I got:

==
FAILURE: Build failed with an exception.

* Where:
Build file







'/home/stoty/workspaces/apache-phoenix/calcite-avatica/release/build.gradle.kts'

line: 213

* What went wrong:
Task with name 'assemble' not found in project ':release'.
==
and I wasn't able to get any further. (I am no Gradle expert)

Phoenix still supports Java 8, so we need the public artifacts to be

Java 8

compatible.
I imagine Phoenix is not the only project that still supports Java

8.


While Avatica is built with

sourceCompatibility = JavaVersion.VERSION_1_8

targetCompatibility = JavaVersion.VERSION_1_8
It does not seem to set the boot classpath, which does not guarantee

actual

backwards compatibility.
Depending on the Java APIs used, the generated code may or may not

work

on

Java 8 JVMs.

The easy workaround is to use the -release flag instead, but that

doesn't

work on Java 8, so this needs
some hacking of the build system.

best regards
Istvan


On Mon, Nov 27, 2023 at 7:13 AM Benchao Li 

wrote:



Thanks Francis for pointing it out, '-Pcheckstyle.version=9.3'

works

fine.


My vote is +1 (binding).

Francis Chuang  

[jira] [Created] (CALCITE-6140) add percentile test on SqlParserTest

[Jira]

蔡灿材 created CALCITE-6140:


 Summary: add percentile test on SqlParserTest
 Key: CALCITE-6140
 URL: https://issues.apache.org/jira/browse/CALCITE-6140
 Project: Calcite
  Issue Type: Test
  Components: tests
Affects Versions: 1.36.0
Reporter: 蔡灿材
 Fix For: 1.37.0


Missing percentile test examples



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

Re: Double quote does not work as literal quote string

[Hongyu Guo]

I think maybe BigQuery Lex is what you need. Try
```
SqlParser.Config config = sparkDialect.configureParser(SqlParser.config())
.withLex(Lex.BIG_QUERY);
```

hongyu


On Tue, Nov 28, 2023 at 6:49 PM 武鹏  wrote:

> Hi all,
> I tried our SQL parser on version 1.32.0 and 1.36.0.
> I used double quote(") as literal quote string in my sql expression, and
> set it on my parser config, but it threw a sql parse exception:
> org.apache.calcite.sql.parser.impl.ParseException: Encountered "\"" at
> line 1, column 26.
>  Was expecting one of:
>  "ABS" ...
>  "ARRAY" ...
>  "AVG" ...
> I am not sure if this is bug, because double quote for literal string is
> not a rare case.
> Here is the my test case:
> public static void main(String[] args) throws Exception {
> String sqlQuery = "case when `Area` in ( \"Region1\", \"Region2\",
> \"Region3\" ) then `Sales` else null end";
> //create spark dialect
> SqlDialect.Context context = SqlDialect.EMPTY_CONTEXT
> .withDatabaseProduct(SqlDialect.DatabaseProduct.SPARK)
>  .withUnquotedCasing(Casing.UNCHANGED)
>  .withNullCollation(NullCollation.LOW)
>  .withIdentifierQuoteString("`")
>  .withLiteralQuoteString("\"");
> SqlDialect sparkDialect = new SparkSqlDialect(context);
> SqlParser.Config config = sparkDialect.configureParser(SqlParser.config());
> // Create an SQL parser
> SqlParser parser = SqlParser.create(sqlQuery, config);
> // Parse the query into an AST. Here the exception occurred
> SqlNode sqlNode = parser.parseExpression();
> }
> Wish to get your reply.
> Thanks,
> Peng
>

Re: avatica-go: resultset offset management

[Egor Ryashin]

Created https://issues.apache.org/jira/browse/CALCITE-6139

I can confirm this is reproduced with 
go/pkg/mod/github.com/apache/calcite-avatica-go/v5@v5.2.0/rows.go

> On 28 Nov 2023, at 02:53, Francis Chuang  wrote:
> 
> Just wanted to quickly update with some investigation I have done with the 
> test project [1]. I am testing against the Avatica HSQLDB server and it 
> appears that the offset is never populated in the frames that are returned 
> from the server, so that might be the cause.
> 
> [1] https://github.com/F21/avatica-go-test
> 
> On 28/11/2023 9:37 am, Julian Hyde wrote:
>> Egor,
>> I don’t know whether your hypothesis is correct, but it sounds plausible and 
>> well-researched. Therefore I think you should put it into a jira case, so 
>> the issue and discussion is on the record. If there is a flaw in your 
>> argument and the jira case is subsequently closed, there’s no shame in that.
>> Julian
>>> On Nov 27, 2023, at 10:59 AM, Egor Ryashin  wrote:
>>> 
>>> Hi all,
>>> 
>>> this exception happens when Apache Druid Avatica protobuf endpoint is used: 
>>> "Druid can only fetch forward. Requested offset”.
>>> I tried to debug that and saw that any simple query fails if it triggers 
>>> fetching of multiple frames. I speculate that when the first ExucuteRequest 
>>> is sent
>>> 
>>> msg := {
>>> StatementHandle:s.handle,
>>> ParameterValues:s.parametersToTypedValues(args),
>>> FirstFrameMaxSize:  s.conn.config.frameMaxSize,
>>> HasParameterValues: true,
>>> }
>>> 
>>> and the result set is created after
>>> 
>>> rsets = append(rsets, {
>>> columns: columns,
>>> done:frame.Done,
>>> offset:  frame.Offset,
>>> data:data,
>>> })
>>> 
>>> then for the next frame FetchRequest is sent but it uses the same 0 offset 
>>> (the data for that offset was returned with the ExecuteRequest)
>>> 
>>> res, err := r.conn.httpClient.post(context.Background(), 
>>> {
>>> ConnectionId: r.conn.connectionId,
>>> StatementId:  r.statementID,
>>> Offset:   resultSet.offset,
>>> FrameMaxSize: r.conn.config.frameMaxSize,
>>> })
>>> 
>>> So, in short, I think Avatica-Go sends 2 requests with the same offset that 
>>> makes Druid to fail.
>>> 
>>> I wonder if anyone with more experience could confirm that?
>>> 
>>> The implementation I mentioned is here: 
>>> go/pkg/mod/github.com/rilldata/calcite-avatica-go/v5@v5.0.0-20230621112535-eea498ff2a3d/rows.go
>>> 
>>> Thanks

[jira] [Created] (CALCITE-6139) Avatica-Go sends the same offset for the FetchRequest

[Egor Ryashin (Jira)]

Egor Ryashin created CALCITE-6139:
-

 Summary: Avatica-Go sends the same offset for the FetchRequest
 Key: CALCITE-6139
 URL: https://issues.apache.org/jira/browse/CALCITE-6139
 Project: Calcite
  Issue Type: Bug
  Components: avatica-go
Affects Versions: avatica-go-5.2.0
Reporter: Egor Ryashin
Assignee: Francis Chuang


This exception happens when *Apache Druid Avatica* protobuf endpoint is used: 
{_}"Druid can only fetch forward. Requested offset”{_}.
I tried to debug that and saw that any simple query fails if it triggers 
fetching of multiple frames. I speculate that when the first *ExucuteRequest* 
is sent


{code:java}
msg := {
StatementHandle:    s.handle,
ParameterValues:    s.parametersToTypedValues(args),
FirstFrameMaxSize:  s.conn.config.frameMaxSize,
HasParameterValues: true,
}{code}


and the result set is created after


{code:java}
rsets = append(rsets, {
columns: columns,
done:    frame.Done,
offset:  frame.Offset,
data:    data,
}){code}


then for the next frame *FetchRequest* is sent but it uses the same 0 offset 
(the data for that offset was returned with the {*}ExecuteRequest{*})

res, err := r.conn.httpClient.post(context.Background(), {
{code:java}
ConnectionId: r.conn.connectionId,
StatementId:  r.statementID,
Offset:   resultSet.offset,
FrameMaxSize: r.conn.config.frameMaxSize,
}){code}


So, in short, I think *Avatica-Go* sends 2 requests with the same offset that 
makes Druid to fail.



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

Double quote does not work as literal quote string

[武鹏]

Hi all,
I tried our SQL parser on version 1.32.0 and 1.36.0.
I used double quote(") as literal quote string in my sql expression, and set it 
on my parser config, but it threw a sql parse exception: 
org.apache.calcite.sql.parser.impl.ParseException: Encountered "\"" at line 1, 
column 26.
 Was expecting one of:
 "ABS" ...
 "ARRAY" ...
 "AVG" ...
I am not sure if this is bug, because double quote for literal string is not a 
rare case.
Here is the my test case:
public static void main(String[] args) throws Exception {
String sqlQuery = "case when `Area` in ( \"Region1\", \"Region2\", \"Region3\" 
) then `Sales` else null end";
//create spark dialect
SqlDialect.Context context = SqlDialect.EMPTY_CONTEXT
.withDatabaseProduct(SqlDialect.DatabaseProduct.SPARK)
 .withUnquotedCasing(Casing.UNCHANGED)
 .withNullCollation(NullCollation.LOW)
 .withIdentifierQuoteString("`")
 .withLiteralQuoteString("\"");
SqlDialect sparkDialect = new SparkSqlDialect(context);
SqlParser.Config config = sparkDialect.configureParser(SqlParser.config());
// Create an SQL parser
SqlParser parser = SqlParser.create(sqlQuery, config);
// Parse the query into an AST. Here the exception occurred
SqlNode sqlNode = parser.parseExpression();
}
Wish to get your reply.
Thanks,
Peng

Re: [VOTE] Release Apache Calcite Avatica 1.24.0 (release candidate 0)

[Istvan Toth]

Francis, The PQS build issue was caused by Avatica including some newer
dependencies (Jackson, IIRC), which include JVM dependent classes. The
current maven-shade-plugin version in PQS cannot handle those JARs, and
needs to be upgraded.
This is a PQS issue, and not  something that Avatica can or should fix.

The JVM 1.8 issue is specific to building Avatica, it doesn't affect
downstream projects that simply depend on the maven binaries.
I only encountered it, because I had to build the RC locally for testing,
and I do not trust the current cross-compile settings in the build.

I have tested Sergey's patch, and it solves the problem, it doesn't look
brittle to me, most related projects have similar workarounds for handling
JVM version differences.

Two different people have hit the JVM 1.8 building issue. Sergey's patch is
a simple fix, which prevents a lot of problems for people trying to build
Avatica in the future. My suggestion is to add it to 1.24.0 .

best regards
Istvan

On Mon, Nov 27, 2023 at 11:38 PM Francis Chuang 
wrote:

> PQS already uses Avatica 1.23.0 [1], which already had the change to
> upgrade checkstyle (which in turn required a newer version of Java).
>
> I wonder if there's something else causing the issue Istvan is seeing.
>
> [1] https://github.com/apache/phoenix-queryserver/blob/master/pom.xml#L88
>
> On 28/11/2023 9:25 am, Julian Hyde wrote:
> > Istvan,
> >
> > You must read the build instructions. If you do not read the build
> instructions, you have no basis for voting -1.
> >
> > Fixing gradle may or may not be the solution. (It might make gradle more
> complex and fragile.)
> >
> > Julian
> >
> >
> >> On Nov 27, 2023, at 2:08 PM, Sergey Nuyanzin 
> wrote:
> >>
> >> Meanwhile I checked the code
> >>
> >> the root cause of the behavior above is upgrade of checkstyle version
> from
> >> 6.18 to 10.3.2 [1]
> >> which happened in 1.23.0, i.e. it is reproducible with 1.23.0
> >>
> >> in this case, please correct me if I'm wrong, this should not be
> considered
> >> as a blocker
> >>
> >> [1] https://issues.apache.org/jira/browse/CALCITE-5329
> >>
> >> On Mon, Nov 27, 2023 at 9:53 PM Sergey Nuyanzin 
> wrote:
> >>
> >>> I created a PR[1]
> >>> The main idea is to introduce another property jdk8.checkstyle which is
> >>> set to 9.3
> >>> before resolving dependency for checkstyle it checks the current java
> >>> version. In case of 1.8 it uses new property otherwise the old one
> >>> new property also allows to keep ability to change version for jdk8
> from
> >>> command line in case it is required as "-Pjdk8.checkstyle.version=X.Y"
> >>>
> >>> Also it allows to compile with jdk 8, 11, 17 without explicitly set
> >>> checkstyle version
> >>>
> >>> [1] https://github.com/apache/calcite-avatica/pull/233
> >>>
> >>> On Mon, Nov 27, 2023 at 8:05 PM Istvan Toth  >
> >>> wrote:
> >>>
>  Can someone who knows Gradel make a patch to get Gradle to set
>  -Pcheckstyle.version=9.3 when it detects Java 1.8  ?
>  This is super simple in Maven with profiles, I expect that it should
> not
>  be
>  very hard in Gradle either.
> 
>  Also, I don't think that the exact JVM patch level has anything to do
> with
>  this, as long as it's Java 1.8.
> 
>  Istvan
> 
>  On Mon, Nov 27, 2023 at 4:05 PM Guillaume Masse
>   wrote:
> 
> > Hi,
> >
> > latest jdk 8 is 8u391, 8u371 is two version behind.
> >
> >
> 
> https://www.oracle.com/java/technologies/javase/8all-relnotes.html#R8u391-BPR
> >
> >
> >
> >
> > On Mon, Nov 27, 2023 at 4:21 AM Istvan Toth
>  >
> > wrote:
> >
> >> -1 (non binding)
> >>
> >> I have successfully built and run the PQS test suite with the
> Avatica
>  RC
> >> with Java 11.
> >> (I had to tweak the PQS maven setup a bit, but that's not Avatica's
> > fault)
> >>
> >> When I tried to do the same with Java 8, I ran into the issues
>  mentioned
> >> above.
> >> I was able to hack around the checkstyle/autostyle issue by removing
>  them
> >> from gradle build files, but then I got:
> >>
> >> ==
> >> FAILURE: Build failed with an exception.
> >>
> >> * Where:
> >> Build file
> >>
> >>
> >
> 
> '/home/stoty/workspaces/apache-phoenix/calcite-avatica/release/build.gradle.kts'
> >> line: 213
> >>
> >> * What went wrong:
> >> Task with name 'assemble' not found in project ':release'.
> >> ==
> >> and I wasn't able to get any further. (I am no Gradle expert)
> >>
> >> Phoenix still supports Java 8, so we need the public artifacts to be
> > Java 8
> >> compatible.
> >> I imagine Phoenix is not the only project that still supports Java
> 8.
> >>
> >> While Avatica is built with
> >>
> >> sourceCompatibility = JavaVersion.VERSION_1_8
> >>
> >>