Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Enrico Olivelli]

Congrat Danny !

Enrico

Il giorno dom 3 nov 2019 alle ore 20:29 Julian Feinauer <
j.feina...@pragmaticminds.de> ha scritto:

> Congratulations Danny! Very well deserved!
>
> Julian
>
> Am 01.11.19, 20:49 schrieb "Muhammad Gelbana" :
>
> Congratulations!
>
> Thanks,
> Gelbana
>
>
> On Fri, Nov 1, 2019 at 9:07 AM Stamatis Zampetakis 
> wrote:
>
> > Congratulations Danny!
> >
> > You are doing an amazing job. The project and the community is
> becoming
> > better every day and your help is much appreciated.
> >
> > Keep up the momentum!
> >
> > Best,
> > Stamatis
> >
> > On Thu, Oct 31, 2019 at 4:41 AM Kurt Young  wrote:
> >
> > > Congratulations Danny!
> > >
> > > Best,
> > > Kurt
> > >
> > >
> > > On Thu, Oct 31, 2019 at 11:18 AM Danny Chan 
> > wrote:
> > >
> > > > Thank you so much colleagues, it’s my honor to work with you!
> > > >
> > > > I have always felt respected and the harmony of the community,
> hope to
> > > > contribute more and I would give help as best as I can, thanks !
> > > >
> > > > Best,
> > > > Danny Chan
> > > > 在 2019年10月31日 +0800 AM5:22，Francis Chuang <
> francischu...@apache.org
> > >，写道：
> > > > > I'm pleased to announce that Danny has accepted an invitation
> to
> > > > > join the Calcite PMC. Danny has been a consistent and helpful
> > > > > figure in the Calcite community for which we are very
> grateful. We
> > > > > look forward to the continued contributions and support.
> > > > >
> > > > > Please join me in congratulating Danny!
> > > > >
> > > > > - Francis (on behalf of the Calcite PMC)
> > > >
> > >
> >
>
>
>

Calcite-Master - Build # 1412 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1412)

Status: Failure

Check console output at https://builds.apache.org/job/Calcite-Master/1412/ to 
view the results.

Re: How to enable cache schema through JDBC properties

[zhaojun]

Hi, Julian

Thanks for your reply.

I have made some sense to  modify configuration of calcite connection.
But still the schema cache mechanism did not work.
Sine I have seen CachingCalciteSchema use guava cache internal, 
so is there any example to make it work instead of creating dynamic schema 
every time.

Regards


--
Zhao Jun
Apache Sharding-Sphere & ServiceComb

> On Nov 5, 2019, at 4:46 AM, Julian Hyde  wrote:
> 
> Possibly related to https://issues.apache.org/jira/browse/CALCITE-3436 
> .
> 
>> On Nov 1, 2019, at 2:08 AM, zhaojun  wrote:
>> 
>> Hi, all
>> 
>> I have found a cache property in JsonSchema, default value was true，calcite 
>> version was 1.20.0
>> But when I create a calcite connection through DriverManager.getConnection, 
>> cache property value was null after Jackson deserialization.
>> My code is like this
>> 
>> ```
>> Properties properties = new Properties();
>> properties.setProperty("schema", schemaName);
>> result.setProperty("schemaFactory", 
>> MemorySchemaFactory.class.getCanonicalName());
>> result.setProperty("lex", "MYSQL");
>> 
>> DriverManager.getConnection(CONNECTION_URL, properties);
>> 
>> ```
>> How can I solve this issue?
>> 
>> Regards
>> 
>> --
>> Zhao Jun
>> Apache Sharding-Sphere & ServiceComb
>> 
> 

Re: Geofunction

[Danny Chan]

Hi, Kiril ~

For “automatically cast” do you mean the implicit type coercion ? For current 
Calcite, we do not support INT -> DECIMAL or FLOAT -> DECIMAL conversion, we 
indeed support varchar -> DECIMAL conversion,

For your example, it is ST_MakePoint(‘1.0', ‘1.0')

Best,
Danny Chan
在 2019年11月5日 +0800 AM4:41，Kirils Mensikovs ，写道：
> Hi,
>
> I am using ST_MakePoint(1.0, 1.0) and that works fine. However, when I try to 
> run following command ST_MakePoint(1, 1), I got exception:
> `No applicable constructor/method found for actual parameters "int, int”`
>
> How to automatically cast int to BigDecimal?
>
> Thanks,
> -Kiril

Re: How to enable cache schema through JDBC properties

[Julian Hyde]

Possibly related to https://issues.apache.org/jira/browse/CALCITE-3436 
.

> On Nov 1, 2019, at 2:08 AM, zhaojun  wrote:
> 
> Hi, all
> 
> I have found a cache property in JsonSchema, default value was true，calcite 
> version was 1.20.0
> But when I create a calcite connection through DriverManager.getConnection, 
> cache property value was null after Jackson deserialization.
> My code is like this
> 
> ```
> Properties properties = new Properties();
> properties.setProperty("schema", schemaName);
> result.setProperty("schemaFactory", 
> MemorySchemaFactory.class.getCanonicalName());
> result.setProperty("lex", "MYSQL");
> 
> DriverManager.getConnection(CONNECTION_URL, properties);
> 
> ```
> How can I solve this issue?
> 
> Regards
> 
> --
> Zhao Jun
> Apache Sharding-Sphere & ServiceComb
> 

Re: Geofunction

[Julian Hyde]

Can you log a bug, please?

> On Nov 1, 2019, at 5:01 AM, Kirils Mensikovs  wrote:
> 
> Hi, 
> 
> I am using ST_MakePoint(1.0, 1.0) and that works fine. However, when I try to 
> run following command ST_MakePoint(1, 1), I got exception:
> `No applicable constructor/method found for actual parameters "int, int”`
> 
> How to automatically cast int to BigDecimal?
> 
> Thanks,
> -Kiril

Geofunction

[Kirils Mensikovs]

Hi, 

I am using ST_MakePoint(1.0, 1.0) and that works fine. However, when I try to 
run following command ST_MakePoint(1, 1), I got exception:
`No applicable constructor/method found for actual parameters "int, int”`

How to automatically cast int to BigDecimal?

Thanks,
-Kiril

Re: use calcite jdbc query mysql only return 10 records

[Andrei Sereda]

This was fixed in 1.18.0 (see CALCITE-2651). You can always manually set
LIMIT.

ES returns by default 10 records. Now calcite uses scrolling to fetch whole
index.


On Mon, Nov 4, 2019 at 2:43 PM James James  wrote:

> Dear
>
> Recently I  ticked in to a problem that use jdbc:calcite method get
> connection and execute query mysql and elasticssearch storage.  the results
> only return 10 records.  checked calcite codes and not found the problems.
> hope get help to fixed my problems
>
> calcite version is 1.17.0
>
> Thank in advance
>

Re: Problem with converters and possibly rule matching

[Julian Hyde]

My definition of a physical property is one that can be changed by a converter. 
For example, the Ordering physical property can be changed by the Sort 
operator. And the Distribution physical property can be changed by the Exchange 
operator. 

Particular physical properties might be baked into the schema — e.g. the fact 
that table T is partitioned on X and sorted by Y — but doesn’t stop them from 
being physical properties; it just saves the effort of sorting/partitioning 
when you execute the query.

Suppose that we have a date column. It could be represented as a string, date, 
or integer. There is the same information content in each, and hence there are 
lossless conversions among those representations. So, I’d say that the 
representation of that column, even though baked into the schema, is a physical 
property too.

Julian


> On Nov 3, 2019, at 11:33 PM, Haisheng Yuan  wrote:
> 
> Hi Vladimir,
> 
> This is still can be done through top-down request approach.
> 
> PhysicalFilter operator should request ANY distribution from child operator, 
> unless there is outer reference in the filter condition, in which case, 
> PhysicalFilter should request SINGLETON or BROADCAST distribution. So in your 
> case, PhysicalFilter request ANY, its required distribution will be enforced 
> on filter's output.
> 
> Regarding index usage, you should have a FIlterTableScan2IndexGet logical 
> transformation rule, and a IndexGet2IndexScan physical implementation rule. 
> Note that IndexGet is a logical operator and IndexScan is a physical 
> operator, which are also used by SQL Server.
> 
> - Haisheng
> 
> --
> 发件人：Vladimir Ozerov
> 日　期：2019年11月01日 17:30:26
> 收件人：
> 主　题：Re: Problem with converters and possibly rule matching
> 
> Hi Stamatis,
> 
> Thank you for your reply. I also thought that we may set the distribution
> trait during logical planning because it is known in advance. And the
> example I gave will work! :-) But unfortunately, it will work only because
> the tree is very simple, and the Project is adjacent to the Scan. This is
> how my reproducer will work in that case:
> 1) Root: enforce "SINGLETON" on Project
> 2) Project: check the logical Scan, infer already resolved distribution,
> then convert to [PhyiscalProject <- PhysicalScan]
> 3) Resolve Root enforcer, adding and Exchange if needed.
> 
> But this stops working as soon as a plan becomes more complex so that it is
> impossible to infer the distribution from the child immediately. E.g.:
> LogicalRoot [distribution=SINGLETON]
> -> LogicalProject // We are here new and cannot produce the physical project
> -> LogicalFilter[distribution=?]
> -> LogicalScan[distribution=REPLICATED]
> 
> This is where your suggestion with cascading enforcement may kick in. But
> now consider that instead of having REPLICATED distribution, which
> satisfies SINGLETON, we have a PARTITIONED distribution, It doesn't satisfy
> SINGLETON, so we have to insert the exchange.
> 
> Before:
> PhysicalRoot [SINGLETON]
> -> PhysicalProject [SINGLETON]
> -> PhysicalFilter [SINGLETON]
> -> LogicalScan [PARTITIONED] // SINGLETON is enforced here
> 
> After:
> PhysicalRoot [SINGLETON]
> -> PhysicalProject [SINGLETON]
> -> PhysicalFilter [SINGLETON]
> -> SingletonExchange [SINGLETON]
> -> PhysicalScan [PARTITIONED]
> 
> But unfortunately, this plan is not optimal. Since we perform Project and
> Filter after the exchange, we now have to reshuffle the whole table. The
> optimal plan would be to pushdown Project and Filter past exchange:
> PhysicalRoot [SINGLETON]
> -> SingletonExchange [SINGLETON]
> -> PhysicalProject [PARTITIONED]
> -> PhysicalFilter [PARTITIONED]
> -> PhysicalScan [PARTITIONED]
> 
> But in order to achieve that, now I need to introduce new rules which will
> attempt to transpose dozens of different operators past exchange, so most
> likely the planning will never finish :-)
> 
> This is why it seems that the bottom-up approach seems to be more natural
> for such cases. Another example is index support. A table may have a number
> of access methods in addition to plain scan, and every such method may
> produce a physical scan with different collations. It is not practical to
> try to enforce something from the top. Instead, we'd better produce
> alternatives from the bottom.
> 
> Basically, Drill tries to mix two approaches. First, it tries to derive
> traits from the child. If it fails and no transformations were created, it
> just stops trait propagation. As a result, an exchange is created on top of
> the operator where we stopped, which again leads to not optimal plans. You
> may observe this in action if you run my reproducer. "testPass" produces an
> optimal plan with help of abstract converters. "testDrill" produces not
> optimal plan with the unnecessary exchange.
> 
> All in all, I cannot get how we can employ distribution metadata and index
> metadata for optimal planning without using a pure 

use calcite jdbc query mysql only return 10 records

[James James]

Dear

Recently I  ticked in to a problem that use jdbc:calcite method get
connection and execute query mysql and elasticssearch storage.  the results
only return 10 records.  checked calcite codes and not found the problems.
hope get help to fixed my problems

calcite version is 1.17.0

Thank in advance

[jira] [Created] (CALCITE-3475) BigQuery SQL dialect unparseCall override broken for UNION ALL

[Steven Talbot (Jira)]

Steven Talbot created CALCITE-3475:
--

 Summary: BigQuery SQL dialect unparseCall override broken for 
UNION ALL
 Key: CALCITE-3475
 URL: https://issues.apache.org/jira/browse/CALCITE-3475
 Project: Calcite
  Issue Type: Bug
Reporter: Steven Talbot


The break on line 
[https://github.com/apache/calcite/blob/ff43dcb95caa251e5fc8120980fc70c8fea8ac40/core/src/main/java/org/apache/calcite/sql/dialect/BigQuerySqlDialect.java#L134]
 should be inside the if. Otherwise, UNION ALL does not trigger the if, hits 
the `break`, and then nothing is unparsed at all!

 

>From looking at the code, INTERSECT and EXCEPT would seem to have the same 
>problem, except per BQ syntax specification at 
>[https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#set-operators],
> the "ALL" is not supported with either of those, so it may not matter (but 
>the code may want to explicitly blow up, saying that those aren't supported?)



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

[jira] [Created] (CALCITE-3474) SqlSimpleParser simplifySql Query token.s NullPointerException

[quxiucheng (Jira)]

quxiucheng created CALCITE-3474:
---

 Summary: SqlSimpleParser simplifySql Query token.s 
NullPointerException
 Key: CALCITE-3474
 URL: https://issues.apache.org/jira/browse/CALCITE-3474
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: quxiucheng
 Fix For: next


 

 

SQL：

 
{code:java}
select ^ from (select * from sales.emp ) a
{code}
use SqlSimpleParser parse sql

Exception:

 

 

 
{code:java}
java.lang.NullPointerExceptionjava.lang.NullPointerException at 
org.apache.calcite.sql.advise.SqlSimpleParser$Query.contains(SqlSimpleParser.java:818)
 at 
org.apache.calcite.sql.advise.SqlSimpleParser$Query.simplify(SqlSimpleParser.java:548)
 at 
org.apache.calcite.sql.advise.SqlSimpleParser$Query.simplifyList(SqlSimpleParser.java:508)
 at 
org.apache.calcite.sql.advise.SqlSimpleParser.simplifySql(SqlSimpleParser.java:171)
 at 
org.apache.calcite.sql.advise.SqlSimpleParser.simplifySql(SqlSimpleParser.java:141)
 at org.apache.calcite.sql.advise.SqlAdvisor.simplifySql(SqlAdvisor.java:556) 
at 
org.apache.calcite.sql.advise.SqlAdvisor.getCompletionHints0(SqlAdvisor.java:222)
 at 
org.apache.calcite.sql.advise.SqlAdvisor.getCompletionHints(SqlAdvisor.java:192)
{code}
 

 

cause:

SqlSimpleParser Token.s

s is null
{code:java}
private boolean contains(String hintToken) {
  for (Token token : tokenList) {
switch (token.type) {
case ID:
  // exception
  if (token.s.equals(hintToken)) {
return true;
  }
  break;
case QUERY:
  if (((Query) token).contains(hintToken)) {
return true;
  }
  break;
}
  }
  return false;
}
{code}
 

 

 

 



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

[jira] [Created] (CALCITE-3473) Unique keys of table scan should contain key column(s)

[Wang Yanlin (Jira)]

Wang Yanlin created CALCITE-3473:


 Summary: Unique keys of table scan should contain key column(s)
 Key: CALCITE-3473
 URL: https://issues.apache.org/jira/browse/CALCITE-3473
 Project: Calcite
  Issue Type: Improvement
Reporter: Wang Yanlin


Currently,   *mq.getUniqueKeys()*  for  *TableScan* returns empty.

However, for table with key column(s) defined, we can refer uniqueness on key 
column(s), so the result should contain key column(s)



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