Re: Time for an Avatica release?

[Haisheng Yuan]

The following PR needs to get into this release:
https://github.com/apache/calcite-avatica/pull/111

It is under review now.

- Haisheng

--
发件人：Francis Chuang
日　期：2019年09月27日 09:18:32
收件人：
主　题：Time for an Avatica release?

Hey everyone,

I wanted to test the waters to see if you guys feel it's time for 
another Avatica release. The last release was in May and there's been 
around 10 new commits since that release. I don't think there are too 
many committed changes to the code but I think preparing for a release 
will provide us with the opportunity to go through the open PRs and try 
to get them committed.

I also note that Vladimir has an open PR to move the build system to 
Gradle. Is this something we should get into this release?

There's also some other PRs where we should consider if they are still 
relevant or should be closed (i.e. 
https://github.com/apache/calcite-avatica/pull/96).

If the community can spend some spare cycles to look at the open PRs 
(currently 11), we will be in a good position to push a new release through.

I am happy to be release manager for this release.

Francis

Time for an Avatica release?

[Francis Chuang]

Hey everyone,

I wanted to test the waters to see if you guys feel it's time for 
another Avatica release. The last release was in May and there's been 
around 10 new commits since that release. I don't think there are too 
many committed changes to the code but I think preparing for a release 
will provide us with the opportunity to go through the open PRs and try 
to get them committed.


I also note that Vladimir has an open PR to move the build system to 
Gradle. Is this something we should get into this release?


There's also some other PRs where we should consider if they are still 
relevant or should be closed (i.e. 
https://github.com/apache/calcite-avatica/pull/96).


If the community can spend some spare cycles to look at the open PRs 
(currently 11), we will be in a good position to push a new release through.


I am happy to be release manager for this release.

Francis

Re: [DISCUSS] [CALCITE-3340] Table Function TUMBLE as an operator in SqlStdOperator

[Rui Wang]

There are discussions happened in PR#1457 and we ended with a consensus:
combine both option 1 and option 2.

More specifically, because the limited operator namespace, we won't
overload operators (won't have two operators called "TUMBLE") and will only
give "TUMBLE" for the new operator. For the old one, it will be renamed,
likely to "TUMBLE_old". Meanwhile, I will add the old TUMBLE to parser and
let parser directly create an operator without caring about operator name.
By doing so GROUP BY TUMBLE will still remain being supported in the future
versions, even it's internal name is already changed.


-Rui

On Wed, Sep 25, 2019 at 1:53 PM Rui Wang  wrote:

> Hi community,
>
> In order to support TUMBLE as a TABLE function (see CALCITE-3272), the
> first step is to add a new operator in SqlStdOperatorTable(which is
> CALCITE-3340).  Note that new operator will need a name, which is the
> syntax used in a query. For example, GROUP BY TUMBE(...) will lead to a
> TUMBLE operator created with a name "TUMBLE".
>
> Thus, for the new operator for TUMBLE as built-in table function, we also
> need to specify a name for it. And there are options: still use "TUMBLE",
> or use a new name, e.g. "TUMBLE_TABLE".
>
> For readers' convenience, start from here I will name GROUP BY TUMBLE as
> the old operator, and new table function one as the new operator.
>
> Option 1 that reuse "TUMBLE" as new operator's name:
> This is called operator overloading in Calcite because Calcite seems two
> operators are overloading by checking their names. It turns out, unlike
> other built-in operators, old TUMBLE is not recognized by Parser directly:
> Parser leaves it as UnresolvedFunction to validator. Then it also turns out
> validator is not favor of overloaded built-in operators: overloaded
> built-in operators will lead to "function not found" because more than one
> built-in operators are found from operator table for TUMBLE based on an
> operator name lookup approach. If more than one built-in operator is found
> by validator, validator will just not match either one.
>
> I am now convinced by many of my exploration, testing, code reading and
> prototyping that the resolution for option 1, is to code *both* old and
> new TUMBLE direclty in Parser, and overrite "SqlOperator,deriveType" for
> *both* old and new operators.
>
> You could check one of my prototype:
> https://github.com/apache/calcite/pull/1457
>
>
> For option 2 that use a new name for new operator's name, e.g.
> "TUMBLE_TALBE"
> Because validator treats two operators as operator overloading if they
> have the same name, using another name is ok. It would be very
> straighforward to let the new operator go through parse, validate, rel
> steps if using a new name (I have proven it in an old verrsion of PR1457
>  but unfortunetly I did a
> force push so that version was overwritten and it cannot be seen now).
>
>
>
> For me it seems like option 2 makes sense and require less work. However I
> do want to hear more opinions from community. Please let me know if you
> have any thought.
>
>
> -Rui
>

Re: auto-format or fix checkstyle by maven command

[Rui Wang]

That's interesting. I explicitly added "static" to the end but spotless
maven did not correct the order.


-Rui

On Thu, Sep 26, 2019 at 1:52 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >One diff, for example,
> >is that spotless imports static first but checkstyle prefers static last,
> >which I haven't found a way to config.
>
> I agree Spotless documentation is a bit vague, however Spotless-Gradle
> orders statics for me.
>
> Here's an example:
> // import statics first
> importOrder("static ", "java.", "javax", "org", "net", "com", "")
> // import statics last
> importOrder("java.", "javax", "org", "net", "com", "", "static ")
>
> The sample is taken from Apache JMeter:
>
> https://github.com/apache/jmeter/blob/6d4610d5e3c5c3128100df3189c3e2f4d7fbe8be/build.gradle.kts#L292
>
>
> Vladimir
>

Re: auto-format or fix checkstyle by maven command

[Vladimir Sitnikov]

>One diff, for example,
>is that spotless imports static first but checkstyle prefers static last,
>which I haven't found a way to config.

I agree Spotless documentation is a bit vague, however Spotless-Gradle
orders statics for me.

Here's an example:
// import statics first
importOrder("static ", "java.", "javax", "org", "net", "com", "")
// import statics last
importOrder("java.", "javax", "org", "net", "com", "", "static ")

The sample is taken from Apache JMeter:
https://github.com/apache/jmeter/blob/6d4610d5e3c5c3128100df3189c3e2f4d7fbe8be/build.gradle.kts#L292


Vladimir

Re: [DISCUSS] Small contributions

[Julian Hyde]

A few points.

I don’t like the term “hot fix”. A hot fix has an existing meaning[1] - it is a 
patch you apply to your binaries. Let’s not use that term.

Let’s define “small contributions” as contributions that do not modify code and 
therefore will not break anything, do not need a test or documentation change, 
and do not need a CI run.

I am in favor of accepting small contributions. I wasn’t previously.

We can have guidelines about how to label these small contributions (e.g. git 
labels, certain words in the commit message or PR description). But we 
shouldn’t expect or require contributors to follow those guidelines. By their 
nature, these contributors have not had time to read all of our policy 
documents.

Reviewers must know what our policy is, and should massage commit messages tot 
conform to policy.

These kinds of changes are, by definition, very small and simple. A committer 
can review, approve, fix up, and push to master, and close the PR in one go. 
Five minutes. If the PR requires a back-and-forth then it is not a “simple” 
change.

We should not require a JIRA case.

We not apply the usual policy of appending the contributor’s name to the commit 
message. A typical commit message would be “Fix a comment”.

Release manager should remove these kinds of trivial changes from the release 
notes. They add nothing to the release notes.

These kinds of changes do earn “merit” - the basis on which we make people 
committers - but they earn less merit than a bug fix, a new feature, a detailed 
response to a question on the dev list, or a conference talk. I don’t want 
people to believe that they can earn committership by fixing 100 typos.

There can be problems if a community over-relies on small PRs. In particular, 
there is a project in the Incubator that has only one or two regular developers 
but receives hundreds of contributions a few lines long via PRs. The discussion 
occurs in the PRs, and contributors rarely make more than 1 or 2 contributions. 
The problem for the project is that there is no emergent “community”. This is a 
serious problem for that project, and obviously we do not have that problem. 
Still, there is a side effect to the back-and-forth discussion to get a change 
accepted, namely that the individuals get to know each other. We don’t want to 
lose that.


Julian

[1] https://en.wikipedia.org/wiki/Hotfix 




> On Sep 26, 2019, at 5:17 AM, Michael Mior  wrote:
> 
> I thought about a label, but I think it's probably more productive to
> just review the change immediately if it really is something trivial.
> The problem is that labels can only be applied by committers. That's
> why I suggested asking those who submit PRs to include something in
> the PR title. If others think a label would help though, I'm not
> opposed to it.
> --
> Michael Mior
> mm...@apache.org
> 
> Le jeu. 26 sept. 2019 à 07:28, TANG Wen-hui
>  a écrit :
>> 
>> I agree that we should accept these small changes but not create JIRA for 
>> them.
>> In my opinion, maybe we can label the PR of these small changes.  And 
>> process them at regular intervals in case of forgetting.
>> 
>> best,
>> --
>> wenhui
>> 
>> 
>> 
>> winifred.wenhui.t...@gmail.com
>> 
>> From: Haisheng Yuan
>> Date: 2019-09-26 10:17
>> To: Francis Chuang; dev@calcite.apache.org (dev@calcite.apache.org)
>> Subject: Re: Re: [DISCUSS] Small contributions
>>> most of the time, the author of the fix would  have moved on and have
>> forgotten about it, resulting in the improvement falling through the cracks.
>> 
>> Make sense. I think our current position worth reconsidering and I
>> agree with Francis.
>> 
>> - Haisheng
>> 
>> --
>> 发件人：Francis Chuang
>> 日　期：2019年09月26日 09:20:49
>> 收件人：
>> 主　题：Re: [DISCUSS] Small contributions
>> 
>> From personal experience, I think we should accept these small changes.
>> I have had lots of  cases where I am reading code or documentation on
>> Github and found small errors or typos that are easy to fix, so I'd edit
>> directly in Github and open a PR. These changes do improve the codebase
>> and fix errors that could be misleading or confuse future maintainers
>> and users.
>> 
>> It might be easy to say that we want to combine all these small changes
>> into a bigger change, but most of the time, the author of the fix would
>> have moved on and have forgotten about it, resulting in the improvement
>> falling through the cracks. It also makes the amount of effort required
>> to start contributing to the project a bit higher.
>> 
>> With Github integration, trivial fixes like this should be easy to merge
>> with a click of a button and a quick glance at the diff on Github is
>> usually sufficient for review.
>> 
>> I agree with Michael's suggestion that a JIRA should not be created for
>> cases like this. They are also low-hanging fruit to improve the
>> code-base and not accepting them seems like a 

Re: How to connect es5 in the latest mainline code?

[Andrei Sereda]

Hello,

What version of calcite are you using ? Can you try with latest 1.21
 release ?
elasticsearch5 module has been removed a while ago.

Also we recommend using ES 6.2+ with calcite.

Thanks,
Andrei.


On Thu, Sep 26, 2019 at 9:31 AM ipconfig  wrote:

> Hi：
> I want to know how to connect to es5 in the latest mainline code. I
> read the es5 theme in the official documentation and mailing list, but I
> didn't find the answer.
> I tried to connect es5 in the latest mainline code, but it failed.
> I modified the es version in pom.xml to be the same as the version
> in the calcite 1.16-elasticsearch5 directory (5.5.2), but the compiler will
> report an error with the error message: Could not find artifact
> org.elasticsearch.client:elasticsearch-rest -client:jar:5.5.2 in central (
> https://repo.maven.apache.org/maven2)
> My model.json is as follows: {
>"version": "1.0",
>"defaultSchema": "elasticsearch",
>"schemas": [
>  {
>"type": "custom",
>"name": "elasticsearch",
>"factory":
> "org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
>"operand": {
>  "coordinates": "{'10.95.26.17': 9200}"
>}
>  }
>]
> }
>
>
>
>
>
>
>
>
>
>
>
>

How to connect es5 in the latest mainline code?

[ipconfig]

Hi：
I want to know how to connect to es5 in the latest mainline code. I read 
the es5 theme in the official documentation and mailing list, but I didn't find 
the answer.
I tried to connect es5 in the latest mainline code, but it failed.
I modified the es version in pom.xml to be the same as the version in 
the calcite 1.16-elasticsearch5 directory (5.5.2), but the compiler will report 
an error with the error message: Could not find artifact 
org.elasticsearch.client:elasticsearch-rest -client:jar:5.5.2 in central 
(https://repo.maven.apache.org/maven2)
My model.json is as follows: {
   "version": "1.0",
   "defaultSchema": "elasticsearch",
   "schemas": [
 {
   "type": "custom",
   "name": "elasticsearch",
   "factory": 
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
   "operand": {
 "coordinates": "{'10.95.26.17': 9200}"
   }
 }
   ]
}





 





 

Re: Re: [DISCUSS] Small contributions

[Michael Mior]

I thought about a label, but I think it's probably more productive to
just review the change immediately if it really is something trivial.
The problem is that labels can only be applied by committers. That's
why I suggested asking those who submit PRs to include something in
the PR title. If others think a label would help though, I'm not
opposed to it.
--
Michael Mior
mm...@apache.org

Le jeu. 26 sept. 2019 à 07:28, TANG Wen-hui
 a écrit :
>
> I agree that we should accept these small changes but not create JIRA for 
> them.
> In my opinion, maybe we can label the PR of these small changes.  And process 
> them at regular intervals in case of forgetting.
>
> best,
> --
> wenhui
>
>
>
> winifred.wenhui.t...@gmail.com
>
> From: Haisheng Yuan
> Date: 2019-09-26 10:17
> To: Francis Chuang; dev@calcite.apache.org (dev@calcite.apache.org)
> Subject: Re: Re: [DISCUSS] Small contributions
> > most of the time, the author of the fix would  have moved on and have
> forgotten about it, resulting in the improvement falling through the cracks.
>
> Make sense. I think our current position worth reconsidering and I
> agree with Francis.
>
> - Haisheng
>
> --
> 发件人：Francis Chuang
> 日　期：2019年09月26日 09:20:49
> 收件人：
> 主　题：Re: [DISCUSS] Small contributions
>
> From personal experience, I think we should accept these small changes.
> I have had lots of  cases where I am reading code or documentation on
> Github and found small errors or typos that are easy to fix, so I'd edit
> directly in Github and open a PR. These changes do improve the codebase
> and fix errors that could be misleading or confuse future maintainers
> and users.
>
> It might be easy to say that we want to combine all these small changes
> into a bigger change, but most of the time, the author of the fix would
> have moved on and have forgotten about it, resulting in the improvement
> falling through the cracks. It also makes the amount of effort required
> to start contributing to the project a bit higher.
>
> With Github integration, trivial fixes like this should be easy to merge
> with a click of a button and a quick glance at the diff on Github is
> usually sufficient for review.
>
> I agree with Michael's suggestion that a JIRA should not be created for
> cases like this. They are also low-hanging fruit to improve the
> code-base and not accepting them seems like a missed opportunity to me.
>
> Francis
>
> On 26/09/2019 10:46 am, Michael Mior wrote:
> > I have mixed feelings about this, because on one hand, I'd like to
> > have these things corrected but on the other hand, we're already
> > bogged down with PRs. Perhaps a good compromise is to make it clear
> > that a JIRA should not be created and have some type of tag indicated
> > in the title of the PR. This might be a good time to create a pull
> > request template for GitHub that explains some of the policies (e.g.
> > making sure that non-trivial changes DO have a JIRA case).
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le mer. 25 sept. 2019 à 20:42, Julian Hyde  a écrit :
> >>
> >> I noticed this exchange in https://github.com/apache/calcite/pull/1475: 
> >> 
> >>
> >>
> >>> Q. Just curious, does Calcite accept hotfix style PR that fixes typos, 
> >>> comments, etc.?
> >>
> >>> A. As long as they are large enough. But for 1 line typo fix, it is not 
> >>> worth a specific patch, we prefer to accumulate them together.
> >>
> >> This is indeed our current position. And the reason we have given is that 
> >> it takes considerable effort to review and commit a pull request, even a 
> >> small one.
> >>
> >> Should we reconsider this position?
> >>
> >> Julian

Re: Re: [DISCUSS] Small contributions

[TANG Wen-hui]

I agree that we should accept these small changes but not create JIRA for them.
In my opinion, maybe we can label the PR of these small changes.  And process 
them at regular intervals in case of forgetting.

best,
--
wenhui



winifred.wenhui.t...@gmail.com
 
From: Haisheng Yuan
Date: 2019-09-26 10:17
To: Francis Chuang; dev@calcite.apache.org (dev@calcite.apache.org)
Subject: Re: Re: [DISCUSS] Small contributions
> most of the time, the author of the fix would  have moved on and have
forgotten about it, resulting in the improvement falling through the cracks.
 
​Make sense. I think our current position worth reconsidering and I
agree with Francis.
 
- Haisheng
 
--
发件人：Francis Chuang
日　期：2019年09月26日 09:20:49
收件人：
主　题：Re: [DISCUSS] Small contributions
 
From personal experience, I think we should accept these small changes. 
I have had lots of  cases where I am reading code or documentation on 
Github and found small errors or typos that are easy to fix, so I'd edit 
directly in Github and open a PR. These changes do improve the codebase 
and fix errors that could be misleading or confuse future maintainers 
and users.
 
It might be easy to say that we want to combine all these small changes 
into a bigger change, but most of the time, the author of the fix would 
have moved on and have forgotten about it, resulting in the improvement 
falling through the cracks. It also makes the amount of effort required 
to start contributing to the project a bit higher.
 
With Github integration, trivial fixes like this should be easy to merge 
with a click of a button and a quick glance at the diff on Github is 
usually sufficient for review.
 
I agree with Michael's suggestion that a JIRA should not be created for 
cases like this. They are also low-hanging fruit to improve the 
code-base and not accepting them seems like a missed opportunity to me.
 
Francis
 
On 26/09/2019 10:46 am, Michael Mior wrote:
> I have mixed feelings about this, because on one hand, I'd like to
> have these things corrected but on the other hand, we're already
> bogged down with PRs. Perhaps a good compromise is to make it clear
> that a JIRA should not be created and have some type of tag indicated
> in the title of the PR. This might be a good time to create a pull
> request template for GitHub that explains some of the policies (e.g.
> making sure that non-trivial changes DO have a JIRA case).
> --
> Michael Mior
> mm...@apache.org
> 
> Le mer. 25 sept. 2019 à 20:42, Julian Hyde  a écrit :
>>
>> I noticed this exchange in https://github.com/apache/calcite/pull/1475: 
>> 
>>
>>
>>> Q. Just curious, does Calcite accept hotfix style PR that fixes typos, 
>>> comments, etc.?
>>
>>> A. As long as they are large enough. But for 1 line typo fix, it is not 
>>> worth a specific patch, we prefer to accumulate them together.
>>
>> This is indeed our current position. And the reason we have given is that it 
>> takes considerable effort to review and commit a pull request, even a small 
>> one.
>>
>> Should we reconsider this position?
>>
>> Julian

Re: How to modify data for custom tables through Calcite.

[Juan Pan]

Thanks, Danny


I will have a try, but it seems challenging, i thought… 


Regards,
Trista


 Juan Pan


panj...@apache.org
Juan Pan(Trista), Apache ShardingSphere


On 09/26/2019 14:19，Danny Chan wrote：
The ElasticsearchTableScan is a good start to show how it transfers the elastic 
nodes from Convention.NONE to ElasticsearchRel.CONVENTION [1]

[1] 
https://github.com/apache/calcite/blob/c9adf94b0e07f2e9108ef4d1f2ee28c3e42063b3/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchTableScan.java#L79

Best,
Danny Chan
在 2019年9月26日 +0800 PM12:13，Juan Pan ，写道：
@Danny Chan



Thanks Danny, is there any document or test for me to learn `specific 
convention` more?


Regards,
Trista


Juan Pan


panj...@apache.org
Juan Pan(Trista), Apache ShardingSphere


On 09/26/2019 12:02，Danny Chan wrote：
@Rui Wang, Yes, I wrote the Flink-sql-parser module it did support insert 
grammar well.

@Juan Pan you need the converter rules to convert all the nodes to specific 
convention you want, also specify the desired convention in the trait set of 
your planing program.

Best,
Danny Chan
在 2019年9月26日 +0800 AM6:04，Rui Wang ，写道：
Another data point is both BeamSQL and FlinkSQL support DDL by an extensive
way (and I believe it works through Avitica as well).

BeamSQL: [1]
FlinkSQL: [2]


Calcite allows add customized DDL in parser and also in implementation
schema is accessible.

[1]:
https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/codegen/includes/parserImpls.ftl#L149
[2]:
https://github.com/apache/flink/blob/master/flink-table/flink-sql-parser/src/main/codegen/data/Parser.tdd#L430

-Rui

On Wed, Sep 25, 2019 at 2:54 PM Stamatis Zampetakis 
wrote:

Hi Trista,

I think the server module is doing what you are asking for. Have a look in
ServerTest [1].
As Gelbana mentioned the implementation is based on implementations of the
ModifiableTable interface.

Best,
Stamatis

[1]

https://github.com/apache/calcite/blob/master/server/src/test/java/org/apache/calcite/test/ServerTest.java

On Wed, Sep 25, 2019 at 11:29 PM Mohamed Mohsen 
wrote:

I haven't done that before but I would start investigating from this
interface [1]. Please share your experience if you get this done.

[1] org.apache.calcite.schema.ModifiableTable


On Wed, Sep 25, 2019 at 2:00 PM Juan Pan  wrote:

Hi everyone,


Thanks for your attention. I want to know the following description is
right or not?


"Modification has only been worked on for JDBC tables, not for any
custom
tables currently.”


Query SQL on custom table is ok, so i am wondering whether i can
execute
`update/insert/delete` SQL through Calcite on custom tables.


Can anyone give me some ideas?


Really thanks for your help.


Regards,
Trista






Juan Pan


panj...@apache.org
Juan Pan(Trista), Apache ShardingSphere

Re: How to modify data for custom tables through Calcite.

[Danny Chan]

The ElasticsearchTableScan is a good start to show how it transfers the elastic 
nodes from Convention.NONE to ElasticsearchRel.CONVENTION [1]

[1] 
https://github.com/apache/calcite/blob/c9adf94b0e07f2e9108ef4d1f2ee28c3e42063b3/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchTableScan.java#L79

Best,
Danny Chan
在 2019年9月26日 +0800 PM12:13，Juan Pan ，写道：
> @Danny Chan
>
>
>
> Thanks Danny, is there any document or test for me to learn `specific 
> convention` more?
>
>
> Regards,
> Trista
>
>
> Juan Pan
>
>
> panj...@apache.org
> Juan Pan(Trista), Apache ShardingSphere
>
>
> On 09/26/2019 12:02，Danny Chan wrote：
> @Rui Wang, Yes, I wrote the Flink-sql-parser module it did support insert 
> grammar well.
>
> @Juan Pan you need the converter rules to convert all the nodes to specific 
> convention you want, also specify the desired convention in the trait set of 
> your planing program.
>
> Best,
> Danny Chan
> 在 2019年9月26日 +0800 AM6:04，Rui Wang ，写道：
> Another data point is both BeamSQL and FlinkSQL support DDL by an extensive
> way (and I believe it works through Avitica as well).
>
> BeamSQL: [1]
> FlinkSQL: [2]
>
>
> Calcite allows add customized DDL in parser and also in implementation
> schema is accessible.
>
> [1]:
> https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/codegen/includes/parserImpls.ftl#L149
> [2]:
> https://github.com/apache/flink/blob/master/flink-table/flink-sql-parser/src/main/codegen/data/Parser.tdd#L430
>
> -Rui
>
> On Wed, Sep 25, 2019 at 2:54 PM Stamatis Zampetakis 
> wrote:
>
> Hi Trista,
>
> I think the server module is doing what you are asking for. Have a look in
> ServerTest [1].
> As Gelbana mentioned the implementation is based on implementations of the
> ModifiableTable interface.
>
> Best,
> Stamatis
>
> [1]
>
> https://github.com/apache/calcite/blob/master/server/src/test/java/org/apache/calcite/test/ServerTest.java
>
> On Wed, Sep 25, 2019 at 11:29 PM Mohamed Mohsen 
> wrote:
>
> I haven't done that before but I would start investigating from this
> interface [1]. Please share your experience if you get this done.
>
> [1] org.apache.calcite.schema.ModifiableTable
>
>
> On Wed, Sep 25, 2019 at 2:00 PM Juan Pan  wrote:
>
> Hi everyone,
>
>
> Thanks for your attention. I want to know the following description is
> right or not?
>
>
> "Modification has only been worked on for JDBC tables, not for any
> custom
> tables currently.”
>
>
> Query SQL on custom table is ok, so i am wondering whether i can
> execute
> `update/insert/delete` SQL through Calcite on custom tables.
>
>
> Can anyone give me some ideas?
>
>
> Really thanks for your help.
>
>
> Regards,
> Trista
>
>
>
>
>
>
> Juan Pan
>
>
> panj...@apache.org
> Juan Pan(Trista), Apache ShardingSphere
>
>
>
>

[jira] [Created] (CALCITE-3375) calcite concat function

[cui (Jira)]

cui created CALCITE-3375:


 Summary: calcite concat function
 Key: CALCITE-3375
 URL: https://issues.apache.org/jira/browse/CALCITE-3375
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: cui


I use calcite to connect mysql to test, I have two column test data , age(int) 
and name(varchar) and the table name is test.score_new, and I have two row test 
data following:
--

id  nameage
--

1   飞   16
--
when I use the sql : select '飞'||16 or select '飞'||'16' , it will return the 
right result : EXPR$0=飞16
But when I use the sql : select "name"||"age" from "test"."score_new", it will 
return the result : EXPR$0=1,
and sql : select "sid"||"sid" from "test"."score_new", it will return : 
EXPR$0=1,
and sql : select "name"||"name" from "test"."score_new", it will return : 
EXPR$0=0,
the result is not what I want, I want to get the result : 飞16, why ? and How to 
solve this problem



--
This message was sent by Atlassian Jira
(v8.3.4#803005)