Re: About SqlFunctions.java slimming in calcite

[Forward Xu]

hi Tanner,
Thank you very much for your reply.
In the ISO/IEC SQL standard, scalar functions can be classified into the
following types:
1. String functions: Functions for manipulating string data, such as
CONCAT(), SUBSTRING().
2. Numeric functions: Functions for working with numeric data, such as
ABS(), ROUND().
3. Date and time functions: Functions for manipulating date and time data,
such as DATEADD(), DATEDIFF().
4. System functions: Functions providing information about the database
environment and other system-related details, such as CURRENT_DATE,
CURRENT_USER.

Best,
ForwardXu

Tanner Clary  于2024年1月30日周二 12:21写道：

> I don't think it's a bad idea but I'm also not sure whether it's worth the
> time and effort of deciding what functions should be grouped together, etc.
> Seeing as how methods in that class are mostly (always?) called via
> reflection, I think having them in one place is helpful in ensuring
> consistent code style/patterns. Test classes in Calcite, for instance, vary
> in thoroughness, documentation, formatting, etc, but individual tests in
> the same class rarely vary from one another. That's just from a
> maintenance/consistency perspective, if there's some performance issues or
> otherwise that I'm neglecting then maybe it is worth the attention.
>
> Tanner
>
> On Mon, Jan 29, 2024 at 8:02 PM Forward Xu  wrote:
>
> > hi,
> > I noticed that the code file of the SqlFunctions.java class is getting
> > larger and larger and the functions are increasing. I think some
> functions
> > can be broken down into different function classes to slim down
> > SqlFunctions. For example: json functions use JsonFunctions, and only
> > SqlFunctions retain Function name reference.
> >
> > What do you think?
> >
> > Best,
> > ForwardXu
> >
>

About SqlFunctions.java slimming in calcite

[Forward Xu]

hi,
I noticed that the code file of the SqlFunctions.java class is getting
larger and larger and the functions are increasing. I think some functions
can be broken down into different function classes to slim down
SqlFunctions. For example: json functions use JsonFunctions, and only
SqlFunctions retain Function name reference.

What do you think?

Best,
ForwardXu

[jira] [Created] (CALCITE-6189) Improve FormatElementEnumTest

[Forward Xu (Jira)]

Forward Xu created CALCITE-6189:
---

 Summary: Improve FormatElementEnumTest
 Key: CALCITE-6189
 URL: https://issues.apache.org/jira/browse/CALCITE-6189
 Project: Calcite
  Issue Type: Improvement
  Components: tests
Affects Versions: 1.36.0
Reporter: Forward Xu
Assignee: Forward Xu
 Fix For: 1.37.0






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

Re: [MINOR]

[Forward Xu]

If the fix is very small and there is no related work order or issue, we
can briefly describe the problem and explain the reason for the fix when
submitting the PR. If we need to standardize this type of PR submission, we
can form some PR templates or documentation.

Best,
ForwardXu

Julian Hyde  于2024年1月4日周四 04:21写道：

> It's so difficult to agree on a vocabulary that everyone will agree
> on, I don't know whether we should even try.
>
> I follow the universal rule: "When in Rome, do as the Romans do".
> Which is to say, follow the existing standard (even if it's
> undocumented, which it probably is) and don't invent your own. If I'm
> about to make a commit that fixes a typo, or fixes lint errors, or
> upgrades a component, I browse the commit log to see what commit
> messages people have used for similar changes.
>
> Julian
>
> On Wed, Jan 3, 2024 at 4:11 AM Benchao Li  wrote:
> >
> > The word [MINOR] is very coarse-grained to me, as Stamatis mentions
> > above, it may contains small improvements to javadoc, site, test,
> > error message, method/variable name, etc. And it is subjective to the
> > author/committer whether a PR should be minor.
> >
> > Looking at the git history, I found it useful when a commit without
> > Jira id starts with "Site:", "Refactor:", "Code style:", "Lint".
> > Maybe we can add more useful prefixes for common small changes, such
> > as "Mailmap: ", "Javadoc: ", "Typo:". For others which are not very
> > common small changes, just a clear/concise commit message without any
> > prefix is good enough.
> >
> > Anyway, we'd better reach an agreement when we can omit Jira id and
> > consider a PR is small.
> >
> > Stamatis Zampetakis  于2024年1月3日周三 18:27写道：
> > >
> > > The presence of the "minor" keyword in the commit summary is a bit
> > > redundant. I would argue that if the message is precise enough the
> > > person reading it can infer it is minor or not.
> > >
> > > Moreover, the minor classification is subjective. Some people consider
> > > minor things that do not change code at all. Others consider minor
> > > things that don't touch production code. The addition of tests and
> > > fixing a broken build is also considered minor by few people. All
> > > these examples are taken from the current commits which landed in
> > > Calcite.
> > >
> > > For the reasons above, I feel that we don't really need to include
> > > "minor" in the commit summary but don't feel very strongly about it
> > > anyways.
> > >
> > > In the past we agreed that if a change is trivial/minor we don't need
> > > a JIRA id. Although, this is convenient for getting this committed
> > > faster without too much hassle it has some drawbacks.
> > >
> > > If at some point in the future we want to attach more information to a
> > > particular commit, this is not possible since we cannot modify the git
> > > history. When there is a JIRA we can always add new comments and
> > > clarifications there even if the ticket is resolved.
> > >
> > > Having a JIRA id is also a convenient way and readable way for
> > > referring to particular commits. The commit hash can be used to
> > > identify a commit in Apache main branch but if the same commit is
> > > backported to other forks/branches using the hash becomes more
> > > cumbersome. This is especially useful in downstream projects and forks
> > > for tracking that a specific change landed in various branches.
> > >
> > > Maybe in the future we should reconsider the optionality of the JIRA
> > > id in the commit summary. If this happens then [CALCITE-X][MINOR]
> > > would start getting overly long so this may be another argument
> > > against including "minor" in the message.
> > >
> > > Best,
> > > Stamatis
> > >
> > > On Wed, Jan 3, 2024 at 10:25 AM Ran Tao  wrote:
> > > >
> > > > This format most likely comes from other open source projects.
> > > > If calcite has its own specifications, such as how to set the title
> for PRs
> > > > that do not require a jira name,
> > > > IMHO, it can be introduced in the contribution doc.
> > > > Commiters can also review PRs according to this specification.
> > > >
> > > > Best Regards,
> > > > Ran Tao
> > > >
> > > >
> > > > Istvan Toth  于2024年1月3日周三 16:11写道：
> > > >
> > > > > Perhaps the square bracket convention ?
> > > > > If the ticket starts with CALICITE-\d+ , then make sure that the
> JIRA
> > > > > ticket id is between brackets.
> > > > >
> > > > > Also check for Gerrit Change IDs which are often added
> automatically, and a
> > > > > paint to remove.
> > > > >
> > > > > Istvan
> > > > >
> > > > > On Tue, Jan 2, 2024 at 10:50 PM Tanner Clary <
> tannercl...@google.com
> > > > > .invalid>
> > > > > wrote:
> > > > >
> > > > > > I like the [MINOR] prefix because it makes it easy to identify
> simple
> > > > > > commits (via grep or ctrl+f), the same way [CALCITE-1234] makes
> it easy
> > > > > to
> > > > > > find commits related to [CALCITE-1234]. I also like that it
> maintains the
> > > > > > "[...]" styling at the 

Re: Multi-query optimization

[Forward Xu]

Thanks to the community for the related work that has been done, This is a
good discussion,  and I think it can be used in, for example, better
multi-query optimization algorithms, more effective query result caching
strategies, smarter materialized view selection and maintenance methods,
etc. These directions require further research and exploration.

Finally here is a related paper MULTI-QUERY OPTIMIZATION AND APPLICATIONS]

.

Best，
ForwardXu

Julian Hyde  于2024年1月4日周四 04:09写道：

> Multi-query optimization is one of the big challenges of our field.
> Examples of multi-queries:
>  * an INSERT statement that writes into a table but also updates an index,
>  * a DAG that represents an ETL/ELT job;
>  * a query that produces several data sets (say a list of invoices for
> orders and a list of products that need to be restocked);
>  * a query that uses intermediate results more than once.
>
> Common features of multi-queries are multiple output data sets, and
> re-used intermediate results. In other words, the dataflow graph is a
> DAG rather than just a tree.
>
> I think it would be useful to frame the problem by extending SQL so
> that such multi-queries can be represented as a single unit. From that
> would follow extensions to relational algebra, and improvements to
> planner algorithms and cost models.
>
> I would like to hear people's thoughts before I log a Jira case with a
> sketch of the problem.
>
> Related work:
>  * https://issues.apache.org/jira/browse/CALCITE-481 Spool operator
>  * https://issues.apache.org/jira/browse/CALCITE-1440 Multiple RelNodes
>  * https://issues.apache.org/jira/browse/CALCITE-4568 Incremental
> query optimization
>  * https://issues.apache.org/jira/browse/CALCITE-129 Recursive queries
>
> Julian
>

Re: [ANNOUNCE] New Calcite PMC chair: Benchao Li

[Forward Xu]

Congratulations!

Best,
Forward Xu

Hongyu Guo  于2023年12月22日周五 16:59写道：

> Congratulations Benchao!
> Thanks Stamatis for his great work!
>
>
> On Fri, Dec 22, 2023 at 10:58 AM Ran Tao  wrote:
>
> > Congratulations Benchao!
> > and thanks Stamatis for his great job!
> >
> > Best Regards,
> > Ran Tao
> >
> >
> > Benchao Li  于2023年12月22日周五 10:41写道：
> >
> > > Thank you everyone! And thanks Stamatis for being a great chair, twice!
> > >
> > > I'm very honored to be elected as the chair of Calcite for next year.
> > > This is my first time to take this role, so it means that I need to
> > > learn a lot of new things, I will try to follow the great examples
> > > that the previous chairs have set so far and try my best to fulfil my
> > > duties for next year.
> > >
> > > Jiajun Xie  于2023年12月22日周五 09:33写道：
> > > >
> > > > Congratulations Benchao!
> > > > Thanks Stamatis for his great job!
> > > >
> > > > On Fri, 22 Dec 2023 at 05:01, Julian Hyde  wrote:
> > > >
> > > > > Congratulations, Benchao. And thank you - for your work over many
> > > > > years making our community kinder and healthier. I know you will be
> > an
> > > > > excellent PMC chair.
> > > > >
> > > > > Thank you, Stamatis, for serving as chair not once but twice.
> > > > >
> > > > > Julian
> > > > >
> > > > > On Thu, Dec 21, 2023 at 6:40 AM Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > Congratulations !
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > > Il giorno gio 21 dic 2023 alle ore 15:07 Tanner Clary
> > > > > >  ha scritto:
> > > > > > >
> > > > > > > Congrats, Benchao :)
> > > > > > >
> > > > > > > -Tanner
> > > > > > >
> > > > > > > On Thu, Dec 21, 2023 at 2:33 AM Alessandro Solimando <
> > > > > > > alessandro.solima...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Congratulations Benchao, and thanks again to Stamatis for his
> > > great
> > > > > job!
> > > > > > > >
> > > > > > > > On Thu, 21 Dec 2023 at 11:18, Ruben Q L 
> > > wrote:
> > > > > > > >
> > > > > > > > > Congratulations Benchao!!
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Dec 21, 2023 at 10:05 AM Sergey Nuyanzin <
> > > > > snuyan...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Congratulations, Benchao!
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 21, 2023 at 10:47 AM Francis Chuang <
> > > > > > > > > francischu...@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Congratulations, Benchao!
> > > > > > > > > > >
> > > > > > > > > > > On 21/12/2023 8:24 pm, Guangdong Liu wrote:
> > > > > > > > > > > > Congratulations!
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > >
> > > > > > > > > > > > Best Regards
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Liugddx
> > > > > > > > > > > > liug...@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Stamatis Zampetakis 
> > 于2023年12月21日周四
> > > > > 17:18写道：
> > > > > > > > > > > >
> > > > > > > > > > > >> Calcite community members,
> > > > > > > > > > > >>
> > > > > > > > > > > >> I am pleased to announce that we have a new PMC
> chair
> > > and
> > > > > VP as
> > > > > > > > per
> > > > > > > > > > > >> our tradition of rotating the chair once a year. I
> > have
> > > > > resigned,
> > > > > > > > > and
> > > > > > > > > > > >> Benchao Li was duly elected by the PMC and approved
> > > > > unanimously by
> > > > > > > > > the
> > > > > > > > > > > >> Board.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Please join me in congratulating Benchao!
> > > > > > > > > > > >>
> > > > > > > > > > > >> Best regards,
> > > > > > > > > > > >> Stamatis
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best regards,
> > > > > > > > > > Sergey
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > >
> > > Best,
> > > Benchao Li
> > >
> >
>

Re: Feature: Support gremlin adapter

[Forward Xu]

hi

This is a great feature to extend calcite from regular data queries to
graph queries (calculations),
+1 for looking forward to it.

forwardxu

柳尘  于2023年12月24日周日 11:20写道：

> Motivation
>
> Hi, community. Currently, more and more users are using some graph
> databases, such as JanusGraph, HugeGraph, etc.
> To do some relationship representation of personnel social networks,
> It is used to count the activity of each user in the social network. Most
> graph databases are in the graph building and graph traversal stage.
> All will be implemented using Gremlin syntax.
> However, this is very unfriendly to users who are not familiar with gremlin
> syntax. While calcite exists as a query framework,
> It also provides an adapter interface to adapt to different database
> dialects, such as parsing, relational algebra conversion, and query plan
> binding.
> Our company has solved the problem of adapting various graph databases.
> This is my warehouse: https://github.com/kaori-seasons/calcite-gremlin-sql
>
>
> Background
>
> Calcite itself supports the database language expansion of the adapter,
> which enables users to understand the meaning of the grammar.
> Complete the simplification of the dialect. For example, expand SqlNode to
> implement syntax analysis, and expand RelNode to implement logical plan
> mapping.
>
> thinkerpop is an adaptation framework for various graph databases. In this
> framework, gremlin syntax is mentioned for the first time.
> It has now become a universal query layer for graph databases. While
> expanding query statements through calcite’s adapter interface,
> We will also use thinkerpop's universal graph database API to provide
> dialect compatibility for different graph databases.
>
> Give a simple example:
> From
>
> SELECT "key" FROM inttype
>
>  maps to
>
>
> g.V().hasLabel("inttype").group().unfold().select(Column.values).order().by(_.unfold().id()).project("inttype").
>
> by(.project("key").by(.unfold().choose(.has("key"),.values("key"),_.constant("\$%#NULL#
> %\$"
>
>
>
>
>
> The design architecture is divided into three layers.
>
> Analytical syntax layer, relational algebra transformation layer, logical
> plan binding layer.
>
> Parsing syntax layer: In the parsing query statement phase, fields and
> equivalent conditions are split and converted into points and edges.
>
> Relational algebra layer: Split it into a collection of points and edges,
> and convert it into a TableScan during the aggregation/sorting/query stage
> where calcite abstracts it.
> It is convenient to generate query plans based on conditions and field
> information.
> Connection scanning/single table filtering and other methods can be used to
> traverse from any edge/any starting point in the graph
>
> Logical plan binding layer: Bind behaviors such as connection
> scanning/single table filtering/projection to calcite’s planner to generate
> query plans.
>
> The process of generating Gremlin logical plan using select statement:
>
> 1. First of all, all graph databases start from a source point to build the
> graph. We will use the GraphTraversalSource provided by thinkerpop.
> As the origin, extract the syntax of the incoming point and side
> information. This step will be implemented in SqlSchemaGrabber
> 2. Secondly, for select/where/having/order by/group by our plan in the
> parsing phase is as follows:
>
>   - group by: for a point. There are out-degree and in-degree
> attributes in the graph. From the perspective of the data table, it is
> equivalent to converting the table data into IN or OUT.
> These two dimensions are aggregated. This behavior also corresponds to
> the table traversal graph operation. During the graph traversal
> process, fold/unfold tags will be generated, representing the
> direction of graph traversal.
>   - select: For the select operation, the operation of scanning the
> entire table can be regarded as projecting all columns into point
> attributes. The value changes of each column are mapped to the gremlin
> operation of adding points.
>   - where: The filter operation is used in graph computing semantic
> scenarios. It can be regarded as the edges connected by the out-degree
> and in-degree of the filter point, so it does not involve the
> conversion of relational algebra.
>   Instead, it is pushed directly to the logical plan.
>   - order by: In the process of graph traversal, we mentioned that
> fold/unflod will be generated on the path to represent the
> forward/backward direction.
>   If a field is encountered and there is no value that can be sorted,
> we will fall back to the origin of GraphTraversalSource and end the
> sorting operation.
>   If there are values that can be sorted, they will be unified in
> SqlTraversalEngine, in-degree and out-degree will be counted
> separately for aggregation, and then used with group by according to
> label (IN/OUT)
>   - having: The meaning is the same as group by, but the label is
> different (in addition to the IN/OUT 

Re: Apache Calcite add materialized view recommend module

[Forward Xu]

Hi feiheng,


+1 for this.


Forwardxu

Benchao Li  于2022年11月28日周一 20:58写道：

> Hi feiheng,
>
> It's great to hear that you want to contribute this to the community, I'm
> very interested in this.
>
> Is there any design doc or code branch or something that we can see now?
>
> feiheng ye  于2022年11月28日周一 13:47写道：
>
> > -- Forwarded message -
> > 发件人： Julian Hyde 
> > Date: 2022年11月22日周二 03:03
> > Subject: Re: Apache Calcite add materialized view recommend module
> > To: feiheng ye 
> >
> >
> > One-to-one emails are not very efficient. Can you please send to
> > dev@calcite
> > ?
> >
> >
> > > On Nov 17, 2022, at 5:57 PM, feiheng ye 
> > wrote:
> > >
> > > Hi jhyde.
> > >
> > > Nice to meet you.
> > >
> > > I get the fork from github and secondly develop the apache calcite. I
> > found the materialize view function is imperfect and I want to add
> > materialized view auto recommend module.
> > >
> > >
> > > 1. The module input is source RelNode and output is List.
> > > 2. The source RelNode maybe converted by user source sql.
> > > 3. The output  List is recommend materialized views which user
> > can use them to accelerate the source sql.
> > >
> > >
> > > This function is already complete, does the members of Apache Calcite
> > want to add it?
> > >
> > >
> > > Thanks Regards.
> >
>
>
> --
>
> Best,
> Benchao Li
>

Re: [DISCUSS] How we choose a PMC chair

[Forward Xu]

+1

Haisheng Yuan  于2022年7月4日周一 08:32写道：

> +1 to the improvement.
>
> On 2022/07/04 00:13:58 Francis Chuang wrote:
> > +1 I think this is a good idea. We have a lot of capable PMC members and
> > it would be of great benefit to the project if all of them were
> > considered during the PMC chair selection process.
> >
> > On 4/07/2022 9:46 am, Julian Hyde wrote:
> > > As you know, Calcite has a tradition of choosing a new PMC chair (VP)
> > > each year, around the anniversary of the project's graduation[1][2]. I
> > > think this is a great tradition, but I'd like to discuss an
> > > improvement to that process.
> > >
> > > (I'm starting the conversation now - several months after the previous
> > > vote, and several months before the next - so that it's clear that I
> > > am not criticizing the process or the outcome or previous votes.)
> > >
> > > I've noticed that the outgoing chair sends an email on dev@ saying
> > > words to the following effect:
> > >
> > >I think Xyz would be a great person to succeed me.
> > >What do you all think?
> > >
> > > (I fear that I may have started this tradition when, at the end of my
> > > tenure as first chair, I approached Jesus and asked him whether he'd
> > > be prepared to do the job[3]. Mea culpa.)
> > >
> > > After such an outright endorsement, especially on a public list, it
> > > would be churlish for someone to reply "Actually, I think Abc would be
> > > better." As a result, it's rather difficult to have an open debate,
> > > and the candidate selected by the outgoing chair tends to win
> > > unopposed.
> > >
> > > I suggest that the outgoing chair says something like
> > >
> > >It's time to change the PMC chair.
> > >Please send nominations to private@ and the PMC will discuss and
> vote.
> > >
> > > That would allow for several nominations, allow people to give reasons
> > > why they prefer a candidate (without disparaging other candidates),
> > > and lead to a more informed outcome.
> > >
> > > What do you think? Are there any other aspects of the election process
> > > we should change?
> > >
> > > Julian
> > >
> > > [1] https://lists.apache.org/thread/rmj9qm9wlol3nb7z4phddoljbgvypkrt
> > > [2] https://lists.apache.org/thread/5tzb8w655pj2vo9omz20th5jnbn9zww7
> > > [3] https://lists.apache.org/thread/y4wjdj5h1y3sypnlmhpoz9r6bkk3cv6o
> >
>

Re: [ANNOUNCE] New committer: Benchao Li

[Forward Xu]

Congratulations!


Best,

ForwardXu

Francis Chuang  于2022年7月4日周一 10:21写道：

> Congrats!
>
> On 4/07/2022 12:13 pm, Jiajun Xie wrote:
> > Congrat Benchao Li,  Well deserved!
> >
> > On Mon, 4 Jul 2022 at 09:21, Haisheng Yuan  wrote:
> >
> >> Apache Calcite's Project Management Committee (PMC) has invited Benchao
> Li
> >> to
> >> become a committer, and we are pleased to announce that he has accepted.
> >>
> >> Benchao has pushed a lot of high quality patches, fixing and improving
> code
> >> around plan simplification and rules. Apart from code contributions, he
> has
> >> been regularly involved in the discussion and helping out others in the
> >> mailing
> >> list.
> >>
> >> Benchao, welcome, thank you for your contributions, and we look forward
> to
> >> your
> >> further interactions with the community! If you wish, please feel free
> to
> >> tell
> >> us more about yourself and what you are working on.
> >>
> >> Haisheng (on behalf of the Apache Calcite PMC)
> >>
> >
>

Re: [ANNOUNCE] New committer: Jing Zhang

[Forward Xu]

Congratulations!


Best,

ForwardXu

Benchao Li  于2022年7月4日周一 13:11写道：

> Congratulations Jing!
>
> Francis Chuang  于2022年7月4日周一 10:43写道：
>
> > Congrats!
> >
> > On 4/07/2022 12:42 pm, Haisheng Yuan wrote:
> > > Apache Calcite's Project Management Committee (PMC) has invited Jing
> > Zhang
> > > to
> > > become a committer, and we are pleased to announce that she has
> accepted.
> > >
> > > Since Dec 2017, Jing has been an active and continuous contributor to
> the
> > > Apache
> > > Calcite project. She has pushed high quality patches, fixing and
> > improving
> > > code
> > > around streaming plan.
> > >
> > > Jing, welcome, thank you for your contributions, and we look forward to
> > your
> > > further interactions with the community! If you wish, please feel free
> to
> > > tell
> > > us more about yourself and what you are working on.
> > >
> > > Haisheng (on behalf of the Apache Calcite PMC)
> > >
> >
>
>
> --
>
> Best,
> Benchao Li
>

Re: [ANNOUNCE] Vladimir Ozerov joins Calcite PMC

[Forward Xu]

Congratulations Vladimir!


Best,

ForwardXu

Stamatis Zampetakis  于2022年5月25日周三 15:05写道：

> Congratulations Vladimir. You have shown that you care for the project in
> many different ways and it's only natural to see you in the PMC.
>
> Best,
> Stamatis
>
> On Wed, May 25, 2022 at 8:33 AM Haisheng Yuan  wrote:
>
> > Congratulations Vladimir!
> >
> > On 2022/05/25 06:27:16 Michael Mior wrote:
> > > Congratulations Vladimir!
> > >
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > >
> > > Le mar. 24 mai 2022 à 16:47, Ruben Q L  a écrit :
> > >
> > > > I am pleased to announce that Vladimir has accepted an invitation to
> > join
> > > > the Calcite PMC. Vladimir 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 Vladimir!
> > > >
> > > > - Ruben (on behalf of the Calcite PMC)
> > > >
> > >
> >
>

Re: [ANNOUNCE] Chunwei Lei joins Calcite PMC

[Forward Xu]

Congratulations, Chunwei!


Best,

Forwardxu

Stamatis Zampetakis  于2022年5月25日周三 14:46写道：

> Congratulations Chunwei. You have been doing a lot of work for the project
> and this is very much appreciated!
> Thanks for all your efforts.
>
> Best,
> Stamatis
>
> On Wed, May 25, 2022 at 8:32 AM Haisheng Yuan  wrote:
>
> > Congratulations, Chunwei!
> >
> > On 2022/05/25 06:26:35 Michael Mior wrote:
> > > Congratulations and thank you Chunwei!
> > >
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > >
> > > Le mar. 24 mai 2022 à 16:47, Ruben Q L  a écrit :
> > >
> > > > I am pleased to announce that Chunwei has accepted an invitation to
> > join
> > > > the
> > > >  Calcite PMC. Chunwei 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 Chunwei!
> > > >
> > > > - Ruben (on behalf of the Calcite PMC)
> > > >
> > >
> >
>

Re: [ANNOUNCE] New Calcite PMC chair: Ruben Q L

[Forward Xu]

Congratulations to Ruben!  Thanks for serving as Chair during the last
year, Haisheng!


forward

Ruben Q L  于2022年1月20日周四 19:38写道：

> Thanks everyone!
> And thank you Haisheng for being our PMC Chair during last year!
>
>
>
> On Thu, Jan 20, 2022 at 8:52 AM Alessandro Solimando <
> alessandro.solima...@gmail.com> wrote:
>
> > Congratulations to Ruben and thanks a lot to Haisheng!
> >
> > On Thu, 20 Jan 2022 at 08:13, 953396112 <13282155...@qq.com.invalid>
> > wrote:
> >
> > > Congratulations to Ruben!
> > > Thanks for serving as Chair, Haisheng!
> > >
> > >
> > > Best regards,
> > > Zhaohui Xu
> > >
> > >
> > >
> > >
> > > --原始邮件--
> > > 发件人:
> > >   "dev"
> > > <
> > > hy...@apache.org;
> > > 发送时间:2022年1月20日(星期四) 上午10:29
> > > 收件人:"dev" > >
> > > 主题:[ANNOUNCE] New Calcite PMC chair: Ruben Q L
> > >
> > >
> > >
> > > Calcite community members,
> > >
> > > I am pleased to announce that we have a new PMC chair and VP as per our
> > > tradition of rotating the chair once a year. I have resigned, and Ruben
> > Q L
> > > was duly elected by the PMC and approved unanimously by the Board.
> > >
> > > Please join me in congratulating Ruben!
> > >
> > > Best,
> > > Haisheng Yuan
> >
>

Re: [ANNOUNCE] Apache Calcite 1.29.0 released

[Forward Xu]

Thanks very much for being RM for this release, Rui!


Forward


Julian Hyde  于2021年12月27日周一 15:37写道：

> Thanks for being RM, Rui!
>
> I made a few fix-ups:
>  * I made a force push to ensure that
> https://github.com/apache/calcite/commit/cbfe0609edcc4a843d71497f159e3687a834119e
> <
> https://github.com/apache/calcite/commit/cbfe0609edcc4a843d71497f159e3687a834119e>
> is still on the master branch.
>  * I amended
> https://github.com/apache/calcite/commit/fb2e28ae17d28657f86cd78503edc402464a8da7
> <
> https://github.com/apache/calcite/commit/fb2e28ae17d28657f86cd78503edc402464a8da7>
> to fix JdbcTest.java (it asserted that minorVersion < 30, which is no
> longer true)
>  * I revised the release notes, adding "[CALCITE-4547] Support Java 16 and
> 17” to the list of bugs fixed
>  * In the news item, I changed the commit SHA from
> dec167ac18272c0cd8be477d6b162d7a31a62114 to
> cbfe0609edcc4a843d71497f159e3687a834119e. This is important because the
> downloads page is generated from it.
>
> Can someone update the site, and re-generate javadoc?
>
> Julian
>
>
> > On Dec 26, 2021, at 9:17 PM, Francis Chuang 
> wrote:
> >
> > Thanks so much for being RM for this release, Rui!
> >
> > Francis
> >
> > On 27/12/2021 4:16 pm, Rui Wang wrote:
> >> Hi Community,
> >> I am happy to announce that 1.29.0 is released and the Calcite main
> branch
> >> is unlocked now.
> >> -Rui
> >> -- Forwarded message -
> >> From: Rui Wang 
> >> Date: Sun, Dec 26, 2021 at 9:15 PM
> >> Subject: [ANNOUNCE] Apache Calcite 1.29.0 released
> >> To: 
> >> The Apache Calcite team is pleased to announce the release of Apache
> >> Calcite 1.29.0.
> >> Calcite is a dynamic data management framework. Its cost-based
> >> optimizer converts queries, represented in relational algebra, into
> >> executable plans. Calcite supports many front-end languages and
> >> back-end data engines, and includes an SQL parser and, as a
> >> sub-project, the Avatica JDBC driver.
> >> This release comes two months after 1.28.0. It contains contributions
> >> from 23 authors, and resolves 47 issues, comprising of general
> improvements
> >> and bug-fixes. It upgrades log4j2 to 2.17.0 to fix security
> vulnerabilities
> >> like CVE-2021-45105.
> >> You can start using it in Maven by simply updating your dependency to:
> >>   
> >> org.apache.calcite
> >> calcite-core
> >> 1.29.0
> >>   
> >> If you'd like to download the source release, you can find it here:
> >>   https://calcite.apache.org/downloads/
> >> You can read more about the release (including release notes) here:
> >>   https://calcite.apache.org/docs/history.html#v1-29-0
> >> We welcome your help and feedback. For more information on how to
> >> report problems, and to get involved, visit the project website at:
> >>https://calcite.apache.org/
> >> Thanks to everyone involved!
> >> Rui Wang, on behalf of the Apache Calcite Team
>
>

Re: [DISCUSS] State of the project 2021

[Forward Xu]

Thank you very much Ruben for his work.

Ruben PMC chair +1


Forwardxu

Haisheng Yuan  于2021年12月11日周六 09:03写道：

> Hi Calcite community members,
>
> It has been 6 years since Calcite graduated to a top level Apache project.
> I am so excited to witness how vivid the community has become and how far
> we have come.
>
> We have seen 2 releases so far for Calcite this year (with another release
> v1.29.0 ongoing), with each release containing a large amount of changes.
> Specifically, there are many new features introduced: the InnoDB Adaptor,
> three-value logic for SEARCH operator, Enumerable MergeUnion operator, the
> UNIQUE sub-query predicate... as well as the improvements to materialized
> view recognition. We won't see Calcite's continuous improvements without
> the community members' collaboration and dedication.
>
> In terms of Calcite Avatica, we had 2 releases for Avatica and 0 releases
> for Avatica Go.  Avatica consistently has fewer contributors and pull
> requests than Calcite, maybe because it has fewer users and the code hasn't
> changed aggressively. But more contributors and code reviewers are highly
> welcome and appreciated.
>
> I am glad to see that we had several technical meetups, not to mention at
> ApacheCon and StangeLoop, to talk about the use cases and improvements that
> we have done to Calcite. Many thanks to those who presented talks to give
> more people opportunities to know and use Calcite, and more importantly, to
> enrich the Calcite community.
>
> It's been a great privilege to be able to serve as Calcite's PMC chair in
> 2021. It's also been a big learning experience for me and I am grateful to
> those who trusted me and helped me in the journey. I am also extremely
> proud of having this opportunity to work with Calcite contributors and
> committers.
>
> Last but not least, we need to discuss who should be the new PMC chair of
> Calcite after I step down in December. I would like to nominate Ruben
> Quesada Lopez as the first candidate in the vote. Ruben has been a great
> contributor to the project. He has shown a lot of care for the Calcite
> project and the community, which I feel would make him a great PMC chair.
>
> To repeat questions from previous years:
> 1) What else are we doing well in the project?
> 2) What areas do we need to do better?
>
> Please take some time to share your thoughts!
>
> Thanks,
> Haisheng
>

Re: [ANNOUNCE] New committer: Zhaohui Xu

[Forward Xu]

Congratulations, Zhaohui


Forward

JiaTao Tao  于2021年10月12日周二 下午3:18写道：

> Congratulations
>
> Regards!
>
> Aron Tao
>
>
> Alessandro Solimando  于2021年10月7日周四
> 下午3:44写道：
>
> > Congratulations Zhaohui, I have followed some of the contributions on the
> > view-based rewritings, thanks for all the improvements!
> >
> > Best regards,
> > Alessandro
> >
> > On Thu, 7 Oct 2021 at 07:27, Haisheng Yuan  wrote:
> >
> > > Congratulations, Zhaohui, well deserved!
> > >
> > > Haisheng
> > >
> > > On 2021/10/06 21:14:00, Francis Chuang 
> wrote:
> > > > Congratulations!
> > > >
> > > > On 7/10/2021 7:47 am, Stamatis Zampetakis wrote:
> > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > > Zhaohui Xu
> > > > > to
> > > > > become a committer, and we are pleased to announce that they have
> > > accepted.
> > > > >
> > > > > Numbers speak for themselves and Zhaohui has over 30 commits
> already
> > in
> > > > > master
> > > > > and more than 20 open pull requests waiting to get in. Great record
> > so
> > > far
> > > > > including
> > > > > (but not limited to) improvements and fixes in the view based
> > > > > rewriting modules,
> > > > > JSON serialization, metadata, and field trimming.
> > > > >
> > > > > Zhaohui, welcome, thank you for your contributions, and we look
> > > forward to
> > > > > your
> > > > > further interactions with the community! If you wish, please feel
> > free
> > > to
> > > > > tell
> > > > > us more about yourself and what you are working on.
> > > > >
> > > > > Stamatis (on behalf of the Apache Calcite PMC)
> > > > >
> > > >
> > >
> >
>

Re: [ANNOUNCE] New committer: Vladimir Ozerov

[Forward Xu]

Congratulations!


Best，

Forward

Danny Chan  于2021年6月24日周四 上午11:51写道：

> Congrats, Vladimir!
>
> Best,
> Danny Chan
>
> Yanjing Wang  于2021年6月24日周四 上午11:41写道：
>
> > Congrats, Vladimir!
> >
> > Roman Kondakov  于2021年6月24日周四 上午11:22写道：
> >
> > > Congratulations, Vladimir!
> > >
> > > Roman Kondakov
> > >
> > > On 24.06.2021 12:23, 段雄 wrote:
> > > > Congratulations!
> > > >
> > > > XING JIN  于2021年6月24日周四 上午10:21写道：
> > > >
> > > >> Congratulations ~
> > > >>
> > > >> Best,
> > > >> Jin
> > > >>
> > > >> guangyuan wang  于2021年6月24日周四 上午9:50写道：
> > > >>
> > > >>> Congratulations!
> > > >>>
> > > >>> Francis Chuang  于2021年6月24日周四 上午6:39写道：
> > > >>>
> > >  Congrats, Vladimir!
> > > 
> > >  Francis
> > > 
> > >  On 24/06/2021 7:48 am, Haisheng Yuan wrote:
> > > > Congratulations and thanks for your contributions, Vladimir!
> > > >
> > > > Regards,
> > > > Haisheng
> > > >
> > > > On 2021/06/23 21:34:40, Stamatis Zampetakis 
> > > >> wrote:
> > > >> Apache Calcite's Project Management Committee (PMC) has invited
> > > >>> Vladimir
> > > >> Ozerov to
> > > >> become a committer, and we are pleased to announce that he has
> > > >>> accepted.
> > > >>
> > > >> Vladimir is among the few people who know very well the internal
> > >  workings
> > > >> of the
> > > >> Calcite optimizer. He started and participated in many
> discussions
> > > >>> about
> > > >> the core engine and contributed ideas and code for making it
> > better.
> > > >> Moreover, Vladimir has blogged and talked about Calcite in
> various
> > > >> conferences and meetups giving publicity and showcasing the
> > >  capabilities of
> > > >> the project.
> > > >>
> > > >> Vladimir, welcome, thank you for your contributions, and we look
> > >  forward to
> > > >> your
> > > >> further interactions with the community! If you wish, please
> feel
> > > >> free
> > >  to
> > > >> tell
> > > >> us more about yourself and what you are working on.
> > > >>
> > > >> Stamatis (on behalf of the Apache Calcite PMC)
> > > >>
> > > 
> > > >>>
> > > >>
> > > >
> > >
> >
>

Re: Proposal to extend Calcite into a incremental query optimizer

[Forward Xu]

Thanks for sharing +1


forward

Albert  于2021年5月14日周五 下午2:02写道：

> Thanks for sharing
>
>
> 在 2021年5月14日星期五，Julian Hyde  写道：
>
> > During the meeting we agreed to start progressing this contribution in
> the
> > usual Apache Way, with conversations on the dev list and in the
> > https://issues.apache.org/jira/browse/CALCITE-4568 <
> > https://issues.apache.org/jira/browse/CALCITE-4568> JIRA case. So, it
> > should be easy for you to participate.
> >
> > Botong said he would share the slides. (He might be unwilling to make
> them
> > public, because they are his presentation for a conference that has not
> > happened yet. Reach out to him one-to-one.)
> >
> > Next step is for someone on the Alibaba side to create a PR that is
> > rebased on the latest Calcite master, and add a comment to the JIRA case.
> > Then we can discuss what needs to be done for that PR. Code quality,
> adding
> > comments, breaking up into smaller commits, additional tests, renaming
> > packages/classes, restructuring into plugins are all possibilities.
> >
> > Our side of the bargain, as committers, is that we should review in a
> > timely manner, and not move the goal posts — if the contributors make the
> > changes we request then we will land this code in master in a reasonable
> > amount of time.
> >
> > We also discussed incremental view maintenance (IVM). Tempura solves a
> > more general problem (finding the optimal K steps to maintain a
> > materialized view as data arrives in K points in time) but if we set K=2,
> > we can generate a plan for how to update a materialized view given a
> delta
> > table. The plan will be different based on cost - e.g. whether the delta
> > table is small or large. This is a problem that many of our users would
> > like to solve. It will exercise much of Tempura’s code base, and
> encourage
> > contributions.
> >
> > In my opinion, we should do IVM at launch. It should be the main example
> > we use in conference talks, blog posts, etc. When people understand that
> > case, we can explain how we generalize from K=2 to arbitrary K.
> >
> > Julian
> >
> >
> > > On May 13, 2021, at 9:51 AM, Rui Wang  wrote:
> > >
> > > I apologize that I had a wrong impression on the meeting time (I
> thought
> > it
> > > should be on Thursday but it is Wednesday). I can follow up your
> meeting
> > > records if you have any.
> > >
> > >
> > > -Rui
> > >
> > > On Tue, May 11, 2021 at 8:17 PM Botong Huang  wrote:
> > >
> > >> Hi all,
> > >>
> > >> This is a reminder that we are going to have our second discussion
> > meeting
> > >> tomorrow at 10-11pm PST. Please find the link below, everyone is
> > welcome to
> > >> join!
> > >>
> > >> Join Zoom Meeting
> > >> https://uci.zoom.us/j/91986206610
> > >> <
> > >> https://www.google.com/url?q=https%3A%2F%2Fuci.zoom.us%2Fj%
> > 2F91986206610=D=calendar=2=AOvVaw24sxPtI6hbukCSo3nlQsbn
> > >>>
> > >>
> > >> Meeting ID: 919 8620 6610
> > >> One tap mobile
> > >> +16699006833 <(669)%20900-6833>,,91986206610# US (San Jose)
> > >> +12532158782 <(253)%20215-8782>,,91986206610# US (Tacoma)
> > >>
> > >> Dial by your location
> > >>+1 669 900 6833 <(669)%20900-6833> US (San Jose)
> > >>+1 253 215 8782 <(253)%20215-8782> US (Tacoma)
> > >>+1 346 248 7799 <(346)%20248-7799> US (Houston)
> > >>+1 301 715 8592 <(301)%20715-8592> US (Washington DC)
> > >>+1 312 626 6799 <(312)%20626-6799> US (Chicago)
> > >>+1 646 558 8656 <(646)%20558-8656> US (New York)
> > >> Meeting ID: 919 8620 6610
> > >> Find your local number: https://uci.zoom.us/u/acyXcc43Cd
> > >> <
> > >> https://www.google.com/url?q=https%3A%2F%2Fuci.zoom.us%2Fu%
> > 2FacyXcc43Cd=D=calendar=2=AOvVaw2W08kj_8hEx44dryeZlXb6
> > >>>
> > >>
> > >> Join by Skype for Business
> > >> https://uci.zoom.us/skype/91986206610
> > >> <
> > >> https://www.google.com/url?q=https%3A%2F%2Fuci.zoom.us%
> > 2Fskype%2F91986206610=D=calendar=2=
> > AOvVaw3w0M0YYbcjPyBXzNpyyk0Z
> > >>>
> > >>
> > >> Thanks,
> > >> Botong
> > >>
> > >> On Wed, May 5, 2021 at 9:55 AM Botong Huang  wrote:
> > >>
> > >>> Hi Stamatis and all,
> > >>>
> > >>> Thanks for the interest! Let's tentatively schedule the next meeting
> > next
> > >>> Wednesday at May 12, 10pm-11pm PST then. Please let us know if
> there's
> > >> new
> > >>> needs showing up.
> > >>>
> > >>> Best,
> > >>> Botong
> > >>>
> > >>> On Sun, May 2, 2021 at 2:59 PM Stamatis Zampetakis <
> zabe...@gmail.com>
> > >>> wrote:
> > >>>
> >  Hello,
> > 
> >  I really regret missing the first meeting, sorry about that. I added
> > my
> >  preferences in the document.
> >  I will make sure to attend the next one and help as much as I can.
> > 
> >  I didn't have the chance yet to go over the paper but will try to do
> > it
> >  before the next meeting.
> > 
> >  For me the following dates are more convenient than others so it
> would
> > >> be
> >  nice if we could arrange it then.
> > 
> >  Thu, May 6, 

Re: [ANNOUNCE] New committer: Liya Fan

[Forward Xu]

Congratulations Liya!


Best,

Forward

Chunwei Lei  于2021年2月22日周一 上午11:13写道：

> Congratulations Liya!
>
> Best,
> Chunwei
>
>
> On Fri, Feb 12, 2021 at 5:28 PM Fan Liya  wrote:
>
> > Dear all,
> >
> > I want to express my sincere gratitude to you for all your kind help.
> > I feel honored to have the opportunity of working with you in this
> awesome
> > community.
> >
> > In the past years, I have been working on some different components of
> the
> > SQL engine, now in Alibaba, and previously in Microsoft.
> > Through this experience, I find the SQL optimizer especially interesting,
> > because it involves so many interesting problems.
> >
> > In the future, I want to make greater contributions to the community and
> > help our users build better SQL engines.
> >
> > Best,
> > Liya Fan
> >
> >
> > On Thu, Feb 11, 2021 at 1:54 AM Rui Wang  wrote:
> >
> > > Congratulations Liya!
> > >
> > >
> > > -Rui
> > >
> > > On Wed, Feb 10, 2021 at 6:39 AM Michael Mior  wrote:
> > >
> > > > Congratulations and welcome Liya!
> > > > --
> > > > Michael Mior
> > > > mm...@apache.org
> > > >
> > > > Le mer. 10 févr. 2021 à 05:23, Francis Chuang
> > > >  a écrit :
> > > > >
> > > > > Congrats Liya and well deserved!
> > > > >
> > > > > Francis
> > > > >
> > > > > On 10/02/2021 8:53 pm, Stamatis Zampetakis wrote:
> > > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > Liya
> > > > Fan to
> > > > > > become a committer, and we are pleased to announce that they have
> > > > accepted.
> > > > > >
> > > > > > Liya has made a lot of contributions to the project, enhancing
> > > > optimizer
> > > > > > rules,
> > > > > > improving the efficiency of graph traversal algorithms, as well
> as
> > > > fixing
> > > > > > various
> > > > > > bugs in the project.
> > > > > >
> > > > > > Liya, welcome, thank you for your contributions, and we look
> > forward
> > > > to your
> > > > > > further interactions with the community! If you wish, please feel
> > > free
> > > > to
> > > > > > tell
> > > > > > us more about yourself and what you are working on.
> > > > > >
> > > > > > Stamatis (on behalf of the Apache Calcite PMC)
> > > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] State of the project 2020

[Forward Xu]

Hi Stamatis,

Thanks for your great work.


Haisheng, Danny, and Ruben are all excellent. I believe they can do the
work.

This time I will vote for Haisheng first.


Finally, +1 on Haisheng being our next PMC chair.

Best,
Forward



Stamatis Zampetakis  于2020年11月15日周日 上午7:15写道：

> Thanks to all those who shared their thoughts so far!
>
> Most of the suggestions around reviews and PRs sound promising. Summarizing
> we have:
> * Adding component owners for reviews;
> * Cleaning up stale PRs;
> * Freezing master till every JIRA marked for the next release is reviewed;
>
> Having component owners has been discussed in the past [1, 2] but
> the general feeling was against.
> I don't know if now things are different but we could definitely follow-up
> in a separate discussion if people are interested.
>
> Stale PRs is an issue and becoming stale is what is more problematic. If we
> don't review PRs in a timely manner then
> there is a high chance that the contributor will lose interest and the PR
> will never merge. In the past [3], we discussed the possibility of adding a
> bot
> for helping us in this task but the idea was abandoned in the end. If done
> right, I think it can be useful. For instance, sending a reminder on our
> dev list
> if the PR does not have any activity for a certain time could help us maybe
> prioritize this over others.
>
> One simple thing that we can do without too much discussion is active
> committers to assign a number 5/10 PRs to themselves and we make sure
> that they are resolved (merged or closed) for the next release.
>
> Regarding the role of the PMC chair, there were three names mentioned so
> far: Haisheng, Danny, and Ruben. I believe in all of them!
> Depending on the interest from their side and the feedback from the rest of
> the community we will proceed to a vote.
>
> Best,
> Stamatis
>
> [1]
>
> https://lists.apache.org/thread.html/3b1f43b15306b2f1496fd73bda01dcb3a1dba08747b1267e1b5f8187%40%3Cdev.calcite.apache.org%3E
> [2]
>
> https://lists.apache.org/thread.html/7231a09fc9d1bad52c229664e8cb2a3631314b34464c2df10c594745%40%3Cdev.calcite.apache.org%3E
> [3]
>
> https://lists.apache.org/thread.html/e794ec7f36246ec918a409b80759efc30d5433eea08ee564d4ba0c67%40%3Cdev.calcite.apache.org%3E
>
>
> On Wed, Nov 11, 2020 at 10:19 PM Rui Wang  wrote:
>
> > Thanks Stamatis for serving as the PMC chair for Calcite in 2020!
> >
> > One of the highlights I want to give for the PR reviewing/merging area
> was
> > the practice we started to adopt in recent releases: we started to check
> > each JIRA marked with the right release version and see whether there is
> a
> > PR in a good shape that can be merged. And we have built a contract that
> > unless those promising PR are merged, we won't unlock the Calcite
> master. I
> > feel like this practice has proven to be useful (and of course thanks for
> > release managers who have been working on this!).
> >
> >
> > Finally, +1 on Haisheng being our next PMC chair.
> >
> >
> > -Rui
> >
> > On Wed, Nov 11, 2020 at 1:57 AM Ruben Q L  wrote:
> >
> > >  Hello,
> > >
> > > First of all, thanks Stamatis for this detailed "state of the project",
> > and
> > > thanks for your great work as PMC chair throughout this year, I take my
> > hat
> > > off.
> > >
> > > Regarding the PR issue, I agree with Chunwei. It is true that there is
> a
> > > big amount of pending PRs, but some of them are quite old (2 or even 3
> > > years old). Probably we should collectively spend some time to clean-up
> > our
> > > PR backlog, I'm pretty sure many of these PRs could be closed since
> they
> > > might no longer be relevant at this point. I know this is easier said
> > than
> > > done, but at some moment this is an effort that will have to be made.
> > >
> > > On the Avatica topic, personally speaking (but I guess other people
> might
> > > feel the same), this project is a bit of an "unknown", since I do not
> > work
> > > with it directly. Maybe a possible solution to try to "introduce"
> Avatica
> > > to the community and get more people involved could be via a talk in
> our
> > > coming online meetup.
> > >
> > > Finally, +1 on Haisheng being our next PMC chair.
> > >
> > > Best regards,
> > > Ruben
> > >
> > >
> > > On Tue, Nov 10, 2020 at 6:14 PM 953396112 <13282155...@qq.com> wrote:
> > >
> > > > Hi Stamatis,
> > > >
> > > > Thanks for your great work!
> > > >
> > > >
> > > > Calcite is very good at semantic transformation of relational
> algebra.
> > In
> > > > the process of the project, users can optimize relational algebra by
> > > > implementing RelOptRule or RelShuttle and so on, so as to bring
> > > relational
> > > > algebra into physical query engine. Another point is the construction
> > of
> > > > materialized view recognition framework, which realizes the ability
> of
> > > > materialized view recognition of common relational algebra. The
> > > expression
> > > > of relational algebra is very flexible, and it can do better in
> > > identifying

[jira] [Created] (CALCITE-4338) Support MERGE INTO Clause

[Forward Xu (Jira)]

Forward Xu created CALCITE-4338:
---

 Summary: Support MERGE INTO Clause
 Key: CALCITE-4338
 URL: https://issues.apache.org/jira/browse/CALCITE-4338
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu


MERGE INTO target_table 
USING source_table 
ON search_condition
 WHEN MATCHED THEN
 UPDATE SET col1 = value1, col2 = value2,...
 WHERE 
 [DELETE WHERE ]
 WHEN NOT MATCHED THEN
 INSERT (col1,col2,...)
 values(value1,value2,...)
 WHERE ;



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

Re: [ANNOUNCE] New committer: Rui Wang

[Forward Xu]

Congratulations Rui!


Best,

Forward

Fan Liya  于2020年9月10日周四 上午10:07写道：

> Congratulations, Rui!
>
> Best,
> Liya Fan
>
> On Thu, Sep 10, 2020 at 9:45 AM Danny Chan  wrote:
>
> > Congrats Rui!
> >
> > Best,
> > Danny Chan
> >
> >
> >
> > > 在 2020年9月10日，上午6:28，Francis Chuang  写道：
> > >
> > > Congrats Rui!
> >
> >
>

Re: [ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC

[Forward Xu]

Congrats, Ruben!


Best

Forward

XING JIN  于2020年8月12日周三 上午8:58写道：

> Congrats, Ruben!
>
> 953396112 <953396...@qq.com> 于2020年8月12日周三 上午7:47写道：
>
> > Congratulations,Ruben!
> >
> >
> > xzh
> > --原始邮件--
> > 发件人:
> >   "dev"
> > <
> > zabe...@gmail.com;
> > 发送时间:2020年8月12日(星期三) 凌晨5:53
> > 收件人:"dev" >
> > 主题:[ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC
> >
> >
> >
> > I'm pleased to announce that Ruben has accepted an invitation to
> > join the Calcite PMC. Ruben 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 Ruben!
> >
> > - Stamatis (on behalf of the Calcite PMC)
>

Re: [ANNOUNCE] Apache Calcite 1.24.0 released

[Forward Xu]

Thanks! Chunwei! Good job.

The link address of the Presto dialect implementation in
https://calcite.apache.org/news/2020/07/24/release-1.24.0/ seems to be
wrong.

Best,
Forward

Chunwei Lei  于2020年7月26日周日 上午10:30写道：

> > I assume that master is open for commits?
> Yes. The master is open for commits now.
>
>
> Best,
> Chunwei
>
>
> On Sun, Jul 26, 2020 at 5:43 AM Julian Hyde 
> wrote:
>
> > Thanks for being release manager, Chunwei! Great job.
> >
> > I assume that master is open for commits? I have quite a few stacked up:
> > 3923, 4079, 4134, 4128, 4080, 2569, 2160.
> >
> > I’d like Ruben to review 3923/4079 (class loader deadlock), Rui & Michael
> > to review 2569/2160 (rework table functions, and spatial table functions)
> > and would like volunteers to review 4134 (interval expressions), 4080
> > (character literals as column aliases), 4128 (refactor CSV/file
> adapters).
> >
> > Julian
> >
> >
> > > On Jul 25, 2020, at 9:19 AM, Stamatis Zampetakis 
> > wrote:
> > >
> > > Thanks Chunwei for leading this and of course all of our contributors
> for
> > > their high quality work.
> > >
> > > Best,
> > > Stamatis
> > >
> > > On Sat, Jul 25, 2020, 10:27 AM Chunwei Lei 
> > wrote:
> > >
> > >> The Apache Calcite team is pleased to announce the release of Apache
> > >> Calcite 1.24.0.
> > >>
> > >> Calcite is a dynamic data management framework. Its cost-based
> > >> optimizer converts queries, represented in relational algebra, into
> > >> executable plans. Calcite supports many front-end languages and
> > >> back-end data engines, and includes an SQL parser and, as a
> > >> sub-project, the Avatica JDBC driver.
> > >>
> > >> This release comes two months after 1.23.0. It includes more than
> > >> 80 resolved issues, comprising of a few new features as well as
> > >> general improvements and bug-fixes. It includes top-down rule
> > >> apply and upper bound space pruning, Presto dialect and many
> > >> more bug fixes and improvements.
> > >>
> > >> You can start using it in Maven by simply updating your dependency to:
> > >>
> > >>  
> > >>org.apache.calcite
> > >>calcite-core
> > >>1.24.0
> > >>  
> > >>
> > >> If you'd like to download the source release, you can find it here:
> > >>
> > >>  https://calcite.apache.org/downloads/
> > >>
> > >> You can read more about the release (including release notes) here:
> > >>
> > >>  https://calcite.apache.org/news/2020/07/24/release-1.24.0/
> > >>
> > >> We welcome your help and feedback. For more information on how to
> > >> report problems, and to get involved, visit the project website at:
> > >>
> > >>  https://calcite.apache.org/
> > >>
> > >> Thanks to everyone involved!
> > >>
> > >>
> > >> Best,
> > >> Chunwei
> > >>
> >
> >
>

Re: [DISCUSS] Binary files for testing InnoDB adapter

[Forward Xu]

+1


If we can add the function(Example: innodb-java-writer) of generating ibd
files in the next version, I think it will be better. In this way, InnoDB
adapter initially has the capability of a database, and can further improve
the current unit test.


best

Forward

Stamatis Zampetakis  于2020年7月17日周五 上午6:25写道：

> Hello,
>
> It's good to avoid non-readable files when possible but I don't think we
> have to worry too much about it.
>
> The ASF foundation does not require all files in a release to be
> protected by copyright law and lists a few exceptions [1].
>
> The file is a database dump so I don't see much creativity involved so it
> could be classified under the following case.
>
> "A file without any degree of creativity in either its literal elements or
> its structure is not protected by copyright law; therefore, such a file
> does not require a license header."
>
> Based on my understanding of the policy, I don't see a problem leaving this
> file as is even after 1.24 but if there are doubts I can ping legal@.
>
> Best,
> Stamatis
>
> [1] https://www.apache.org/legal/src-headers.html#faq-exceptions
>
>
> On Thu, Jul 16, 2020 at 10:54 PM Enrico Olivelli 
> wrote:
>
> > Il Gio 16 Lug 2020, 21:28 Julian Hyde  ha scritto:
> >
> > > Michael,
> > >
> > > I think that sentence covers the situation where, say, we ship a
> > > .class file without shipping the .java it was generated from.
> > >
> > > In our case, we are shipping the equivalent of the .class file and the
> > > .java file (namely EMP.ibd and the scott.sql that MySQL generated it
> > > from). We have to ship the .class file equivalent (.ibd) because we
> > > don't require that people running the tests have the javac equivalent
> > > (MySQL).
> > >
> > > The concern about auditability remains.
> > >
> >
> > You can wrap the files in a text based format with a readable license
> > header and the test case can unpack the files and use them. It is tricky
> > but it can work
> >
> >
> > Enrico
> >
> >
> > > Julian
> > >
> > > On Thu, Jul 16, 2020 at 8:34 AM Michael Mior  wrote:
> > > >
> > > > I don't personally have a problem with this, but it seems as though
> it
> > > > might violate the release policy. Specifically the statement "It is
> > > > also necessary for the PMC to ensure that the source package is
> > > > sufficient to build any binary artifacts associated with the
> release."
> > > >
> > > > https://www.apache.org/legal/release-policy.html#what
> > > >
> > > > --
> > > > Michael Mior
> > > > mm...@apache.org
> > > >
> > > > Le mer. 15 juil. 2020 à 20:02, Julian Hyde  a
> écrit
> > :
> > > > >
> > > > > TL;DR: PMC members, would you vote for a release 1.24 if it
> includes
> > > > > binary files necessary for testing?
> > > > >
> > > > > I would like to include the InnoDB adapter [1] in release 1.24. It
> is
> > > > > well written, well documented, and it is ready.
> > > > >
> > > > > There is one problem: there are some binary files (in InnoDB
> format)
> > > > > [2] that are included for testing. As a general rule, Apache does
> not
> > > > > release binary files as part of the source release because they are
> > > > > difficult to audit for provenance.
> > > > >
> > > > > I think we should make an exception, for just release 1.24, because
> > > > > the files are small (just EMP and DEPT tables) and generated by
> hand.
> > > > >
> > > > > I have asked the author to do a follow-up task to remove the files
> > > > > before next release.
> > > > >
> > > > > PMC members, please reply to this email and indicate whether this
> > > > > would cause you to vote -1 on the upcoming release.
> > > > >
> > > > > Julian
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/CALCITE-4034
> > > > >
> > > > > [2]
> > >
> >
> https://github.com/apache/calcite/tree/b5e1622e7a43a3468a880c374f9161eee3ffa1ea/innodb/src/test/resources/data
> > >
> >
>

Re: Draft board report for July 2020

[Forward Xu]

Looks good!

Thanks Stamatis！


Best,

Forward



Chunwei Lei  于2020年7月3日周五 上午10:47写道：

> Looks great! Thanks Stamatis~~
>
> Best,
> Chunwei
>
>
> On Fri, Jul 3, 2020 at 9:08 AM Julian Hyde  wrote:
>
> > Looks good. Thanks!
> >
> > I regard the report as for the quarter (April 1st - June 30th), so the
> > Avatica-go release should rightly go into the Summer report.
> >
> > Julian
> >
> > > On Jul 2, 2020, at 4:31 AM, Stamatis Zampetakis 
> > wrote:
> > >
> > > Attached below is a draft of this month's board report. I plan to
> > submit it
> > > on July 7. Please let me know if you have any additions or corrections.
> > >
> > > ## Description:
> > > Apache Calcite is a highly customizable framework for parsing and
> > planning
> > > queries on data in a wide variety of formats. It allows database-like
> > > access,
> > > and in particular a SQL interface and advanced query optimization, for
> > data
> > > not
> > > residing in a traditional database.
> > >
> > > Avatica is a sub-project within Calcite and provides a framework for
> > > building
> > > local and remote JDBC and ODBC database drivers. Avatica has an
> > independent
> > > release schedule and its own repository.
> > >
> > > ## Issues:
> > > There are no issues requiring board attention.
> > >
> > > ## Membership Data:
> > > Apache Calcite was founded 2015-10-22 (4 years ago)
> > > There are currently 50 committers and 22 PMC members in this project.
> > > The Committer-to-PMC ratio is roughly 7:3.
> > >
> > > Community changes, past quarter:
> > > - No new PMC members. Last addition was Haisheng Yuan on 2019-11-11.
> > > - Forward Xu was added as committer on 2020-04-28
> > > - Xing Jin was added as committer on 2020-04-28
> > > - Vineet Garg was added as committer on 2020-04-24
> > > - Yanlin Wang was added as committer on 2020-04-28
> > >
> > > ## Project Activity:
> > > Avatica 1.17.0 was released on 2020-06-22. It is a small routine
> release
> > > that includes a
> > > few dependency updates and bug fixes.
> > >
> > > [Include Avatica Go if it is released on time]
> > > Avatica Go 5.0.0 was released on 2020-07-XX. It is a major release of
> > > Avatica Go with a number of improvements and a breaking change
> affecting
> > > connection metadata. Worth mentioning the support for batching query
> > string
> > > parameters in the DSN allowing updates to the server to be executed
> once
> > > Close() is called on the prepared statement.
> > >
> > > Calcite 1.23.0 was released on 2020-05-23, including more than 100
> > resolved
> > > issues. It includes many new futures such as an SQL dialect for
> > ClickHouse
> > > and SESSION/HOP table functions (particularly useful for queries on
> > > streams), along with significant improvements to the optimizer reducing
> > > optimization latency up to a factor of 50x for some complex queries.
> > >
> > > [Do we have any talks or new adopters to put in the report?]
> > >
> > > ## Community Health:
> > >
> > > The overall activity on the mailing lists has increased (-7% dev@,
> +27%
> > > issues@) with many interesting topics some very important for the
> > future of
> > > the project such as the redesign of the optimizer, modelling indexes,
> > and a
> > > big refactoring of the ruleset.
> > >
> > > Regarding opened/resolved issues the things are rather balanced. We
> had a
> > > slight decrease in new issues (-6% JIRA, -13% GitHub) counterbalanced
> by
> > a
> > > small increase in closed issues (+14% JIRA, +4% GitHub). Since we have
> a
> > > large
> > > backlog of PRs, the increased ratio of closed PRs/issues is a good
> sign.
> > >
> > > Although the number of commits has slightly decreased in the past
> quarter
> > > (-16%) we had more code contributors (+17%) among them some new faces
> > which
> > > is
> > > very promising for the future of the project.
> >
>

Re: [ANNOUNCE] Apache Calcite 1.23.0 released

[Forward Xu]

Nice job, Haisheng! Thanks.


Best,

ForwardXu

Enrico Olivelli  于2020年5月28日周四 下午1:48写道：

> Great
>
>
> Enrico
>
> Il Gio 28 Mag 2020, 05:12 Chunwei Lei  ha scritto:
>
> > Nice job, Haisheng!
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Thu, May 28, 2020 at 10:42 AM XING JIN 
> wrote:
> >
> > > Thanks a lot for driving this, Haisheng!
> > >
> > > Best,
> > > Jin
> > >
> > > Stamatis Zampetakis  于2020年5月28日周四 上午7:14写道：
> > >
> > > > Many thanks again Haisheng, the release has your signature on it and
> it
> > > is
> > > > in many places :)
> > > >
> > > > On Wed, May 27, 2020 at 9:34 PM Haisheng Yuan 
> > wrote:
> > > >
> > > > > The Apache Calcite team is pleased to announce the release of
> Apache
> > > > > Calcite 1.23.0.
> > > > >
> > > > > Calcite is a dynamic data management framework. Its cost-based
> > > > > optimizer converts queries, represented in relational algebra, into
> > > > > executable plans. Calcite supports many front-end languages and
> > > > > back-end data engines, and includes an SQL parser and, as a
> > > > > sub-project, the Avatica JDBC driver.
> > > > >
> > > > > This release comes two months after 1.22.0. It includes more than
> > > > > 100 resolved issues, comprising of a few new features as well as
> > > > > general improvements and bug-fixes. It includes support for top
> > > > > down trait request and trait enforcement without abstract
> converter,
> > > > > ClickHouse dialect, SESSION and HOP Table functions, and many
> > > > > more bug fixes and improvements.
> > > > >
> > > > > You can start using it in Maven by simply updating your dependency
> > to:
> > > > >
> > > > >   
> > > > > org.apache.calcite
> > > > > calcite-core
> > > > > 1.23.0
> > > > >   
> > > > >
> > > > > If you'd like to download the source release, you can find it here:
> > > > >
> > > > >   https://calcite.apache.org/downloads/
> > > > >
> > > > > You can read more about the release (including release notes) here:
> > > > >
> > > > >   https://calcite.apache.org/news/2020/05/23/release-1.23.0/
> > > > >
> > > > > We welcome your help and feedback. For more information on how to
> > > > > report problems, and to get involved, visit the project website at:
> > > > >
> > > > >   https://calcite.apache.org/
> > > > >
> > > > > Thanks to everyone involved!
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)

[Forward Xu]

Thanks, Haisheng!


Environment: Mac-OS Mojave (10.14.6)

JDK version: 1.8.0_211


Release notes: OK

Build with tests: OK

Checksums and signatures: OK


Vote:

+1 (non-binding)


Best,

Forward

XING JIN  于2020年5月19日周二 上午10:53写道：

> Thanks, Haisheng ~
>
> Local Calcite build with tests enabled on Linux: *OK*
> Calcite-based system test suite: *OK*
>
> Vote:
> +1 (non-binding)
>
> Francis Chuang  于2020年5月18日周一 下午2:00写道：
>
> > Thanks for making this release available for voting, Haisheng!
> >
> > Verified GPG signature - OK
> > Verified SHA512 - OK
> > Ran tests per HOWTO (./gradlew check) - OK
> > Quickly skimmed release notes - OK
> > Spotted checked a few JARs in the Maven repository - OK
> >
> > Environment (OpenJDK:latest docker container):
> > Gradle 6.3 (via gradlew)
> > Debian GNU/Linux 8
> > openjdk version "1.8.0_111"
> > OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2~bpo8+1-b14)
> > OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
> >
> > My vote is: +1 (binding)
> >
> > Francis
> >
> > On 16/05/2020 2:02 pm, Haisheng Yuan wrote:
> > > Hi all,
> > >
> > > I have created a build for Apache Calcite 1.23.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/blob/calcite-1.23.0-rc1/site/_docs/history.md
> > >
> > > The commit to be voted upon:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=b708fdc46d4c5fd4c5a6c7a398823318a7b4dce3
> > >
> > > Its hash is b708fdc46d4c5fd4c5a6c7a398823318a7b4dce3
> > >
> > > Tag:
> > > https://github.com/apache/calcite/tree/calcite-1.23.0-rc1
> > >
> > > The artifacts to be voted on are located here:
> > >
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.23.0-rc1
> > > (revision 39622)
> > >
> > > The hashes of the artifacts are as follows:
> > >
> >
> 961c4f13199e199c669a6168ba655a9492bdd80d644da375a684b732c0b628b8a2ffacea5da97c82e8702a8e3bf7a1f58784baa49509fb3c48ef593259e11f46
> > > *apache-calcite-1.23.0-src.tar.gz
> > >
> > > A staged Maven repository is available for review at:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecalcite-1089/org/apache/calcite/
> > >
> > > Release artifacts are signed with the following key:
> > > https://dist.apache.org/repos/dist/release/calcite/KEYS
> > >
> > > N.B.
> > > To create the jars and test Apache Calcite: "./gradlew build".
> > >
> > > If you do not have a Java 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 1.23.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 1.23.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)
> > >
> > > Thanks,
> > > Haisheng Yuan
> > >
> >
>

[discuss] Implement Elasticsearch jdbc driver

[Forward Xu]

Hi everybody,

I'd like to kick off a discussion on Implement Elasticsearch jdbc driver in
calcite.

Calcite has already implemented the elasticsearch adapter. I want to add
standard jdbc driver support based on the adapter. The advantage is that it
can be more easily used for visualization through the jdbc driver-based bi
system. It can also enhance the DDL and DML of the current elasticsearch
adapter. Implement es jdbc driver similar to aws open source [1]

Would love to hear your thoughts.

Best,
Forward

[1]https://github.com/opendistro-for-elasticsearch/sql

Re: [ANNOUNCE] New committer: Forward Xu

[Forward Xu]

Thank you everyone for your warm welcome!
I'm working in the TBDS team of Tencent in Shenzhen. TBDS (Tencent Big Data
Suite) is similar to Alibaba's EMR, TBDS is a big data ecosystem. I am
responsible for Oceanus(flink streaming jobs) and Tdbank (Tencent real-time
data collection system). I‘m very happy to become calcite committer and
looking forward to make more contributions.

Best,
Forward

Zoltan Haindrich  于2020年4月29日周三 下午1:58写道：

> Congratulations!
>
> On 4/29/20 7:31 AM, Enrico Olivelli wrote:
> > Congrats!
> >
> > Enrico
> >
> > Il Mer 29 Apr 2020, 04:52 Feng Zhu  ha scritto:
> >
> >>   Congrations! Forward!
> >>
> >> best,
> >> Feng
> >>
> >> Chunwei Lei  于2020年4月29日周三 上午10:17写道：
> >>
> >>> Congrats, Forward!
> >>>
> >>>
> >>>
> >>> Best,
> >>> Chunwei
> >>>
> >>>
> >>> On Wed, Apr 29, 2020 at 6:46 AM Rui Wang  wrote:
> >>>
> >>>> Congrats!
> >>>>
> >>>>
> >>>> -Rui
> >>>>
> >>>> On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang <
> >> francischu...@apache.org
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Congrats, Forward!
> >>>>>
> >>>>> Francis
> >>>>>
> >>>>> On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:
> >>>>>> Apache Calcite's Project Management Committee (PMC) has invited
> >>> Forward
> >>>>> Xu
> >>>>>> to
> >>>>>> become a committer, and we are pleased to announce that he has
> >>>> accepted.
> >>>>>>
> >>>>>> Forward has been helping the project for some time now. He added
> >> many
> >>>> new
> >>>>>> SQL
> >>>>>> functions to the project and is one of our JSON experts. On top of
> >>>> that,
> >>>>> and
> >>>>>> other fixes, he is the one who added the Redis adapter to the
> >>> project.
> >>>>>>
> >>>>>> Forward, welcome, thank you for your contributions, and we look
> >>> forward
> >>>>> to
> >>>>>> your
> >>>>>> further interactions with the community! If you wish, please feel
> >>> free
> >>>> to
> >>>>>> tell
> >>>>>> us more about yourself and what you are working on.
> >>>>>>
> >>>>>> Stamatis (on behalf of the Apache Calcite PMC)
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

Re: [ANNOUNCE] New committer: Wang Yanlin

[Forward Xu]

Congrats


Best,

Forward

953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:26写道：

> Congrats, Wang Yanlin!
>
>
>
>
> ---Original---
> From: "Stamatis Zampetakis" Date: Wed, Apr 29, 2020 05:51 AM
> To: "dev" Subject: [ANNOUNCE] New committer: Wang Yanlin
>
>
> Apache Calcite's Project Management Committee (PMC) has invited Wang Yanlin
> to
> become a committer, and we are pleased to announce that he has accepted.
>
> Wang has pushed numerous fixes and improvements to the project, landing in
> total
> the impressive number of 30 commits to the master. Among other things, he
> contributed some important features in the Interpreter.
>
> Wang, welcome, thank you for your contributions, and we look forward your
> further interactions with the community! If you wish, please feel free to
> tell
> us more about yourself and what you are working on.
>
> Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Jin Xing

[Forward Xu]

Congrats


best,

Forward

953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:21写道：

> Congrats, Jin Xing!
>
>
> ---Original---
> From: "Stamatis Zampetakis" Date: Wed, Apr 29, 2020 05:47 AM
> To: "dev" Subject: [ANNOUNCE] New committer: Jin Xing
>
>
> Apache Calcite's Project Management Committee (PMC) has invited Jin Xing to
> become a committer, and we are pleased to announce that he has accepted.
>
> Jin has contributed a lot of code in the project and many
> recent improvements in
> materialized view matching have his signature on them. Apart from code
> contributions, Jin provides valuable help to the community by doing reviews
> and
> answering questions in the devlist.
>
> Jin, welcome, thank you for your contributions, and we look forward to your
> further interactions with the community! If you wish, please feel free to
> tell
> us more about yourself and what you are working on.
>
> Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Vineet Garg

[Forward Xu]

Congratulations

best,
Forward

Francis Chuang  于2020年4月26日周日 上午6:04写道：

> Congrats, Vineet!
>
> On 26/04/2020 7:52 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Vineet
> > Garg to become a committer, and we are pleased to announce that he
> > has accepted.
> >
> > With the first code contribution in Calcite back in 2017, Vineet is
> > definitely
> > not new to the project. Since then he has contributed many patches,
> > fixing and improving various modules of Calcite, notably things around
> > subqueries.
> >
> > Vineet, welcome, thank you for your contributions, and we look forward
> > your further interactions with the community! If you wish, please feel
> > free to tell us more about yourself and what you are working on.
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
> >
>

[jira] [Created] (CALCITE-3941) Add the default mode to the path in the Json functions.

[Forward Xu (Jira)]

Forward Xu created CALCITE-3941:
---

 Summary: Add the default mode to the path in the Json functions.
 Key: CALCITE-3941
 URL: https://issues.apache.org/jira/browse/CALCITE-3941
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Forward Xu
Assignee: Forward Xu


Add the default mode to the path in the JSON functions.

before:

json_exists ('\{"foo": "bar"}', 'lax $ .foo') or

json_exists ('\{"foo": "bar"}', 'strict $ .foo')

after:

json_exists ('\{"foo": "bar"}', '$ .foo')



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

Re: [discuss] Add the default mode to the path in the Json functions.

[Forward Xu]

Hi Julian,
Thank you for bringing such a good shared link, there are some areas in the
JSON function that need to be improved and implemented. I will continue to
improve it.

Forward

Julian Hyde  于2020年4月21日周二 上午1:28写道：

> Speaking of JSON functions, JOOQ creator Lukas Eder has been giving JSON
> functions in MySQL/MariaDB a good workout over the last few days. It’s
> amusing to read what he has discovered: https://twitter.com/lukaseder <
> https://twitter.com/lukaseder>
>
> Julian
>
>
> > On Apr 20, 2020, at 8:27 AM, Stamatis Zampetakis 
> wrote:
> >
> > Hi,
> >
> > I know that Oracle uses lax by default [1] but I don't remember what
> other
> > DBMS do.
> >
> > In any case adopting a default mode sounds like a reasonable thing to do.
> >
> > Best,
> > Stamatis
> >
> > [1] https://docs.oracle.com/database/121/ADXDB/json.htm#ADXDB6259
> >
> >
> > On Mon, Apr 20, 2020, 7:28 AM Chunwei Lei 
> wrote:
> >
> >> Thank you for proposing this, Forward.
> >>
> >> I am wondering whether it is really useful for users who want to use
> these
> >> functions
> >> since they probably know what the syntax is. But personally I would
> like to
> >> have the
> >> default mode since it is more convenient.
> >>
> >>
> >> Best,
> >> Chunwei
> >>
> >>
> >> On Sun, Apr 19, 2020 at 9:51 AM Forward Xu 
> wrote:
> >>
> >>> hi everyone, I recently found some discussable optimizations when I
> >>> contributed the flip-90 [1] Json functions:
> >>> The current json functions in calcite: JSON_EXISTS, JSON_VALUE,
> >> JSON_QUERY,
> >>> JSON_OBJECT, JSON_OBJECTAGG, JSON_ARRAY, JSON_ARRAYAGG and IS JSON
> >>> predication functions. These functions are implemented based on the SQL
> >>> 2016-2017 standard [2]. According to this standard, the path of the
> json
> >>> function must be used in one of strict or lax mode. such as:
> >>> json_exists ('{"foo": "bar"}', 'lax $ .foo') or
> >>> json_exists ('{"foo": "bar"}', 'strict $ .foo')
> >>> Can we give a default mode to simplify the use of lax and strict. For
> >>> example, we default to lax mode. In this way, the use of our json
> >> function
> >>> can be simplified to:
> >>> json_exists ('{"foo": "bar"}', '$ .foo')
> >>> Implementation idea improvement JsonFunctions jsonApiCommonSyntax path
> >>> judgment to increase the default lax mode logic.
> >>> Of course, these changes are not described in SQL2016-2017.
> >>> I want to hear your opinion here.
> >>>
> >>> [1]
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=141724550
> >>> [2]
> >>>
> >>>
> >>
> https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip
> >>>
> >>
>
>

[discuss] Add the default mode to the path in the Json functions.

[Forward Xu]

hi everyone, I recently found some discussable optimizations when I
contributed the flip-90 [1] Json functions:
The current json functions in calcite: JSON_EXISTS, JSON_VALUE, JSON_QUERY,
JSON_OBJECT, JSON_OBJECTAGG, JSON_ARRAY, JSON_ARRAYAGG and IS JSON
predication functions. These functions are implemented based on the SQL
2016-2017 standard [2]. According to this standard, the path of the json
function must be used in one of strict or lax mode. such as:
json_exists ('{"foo": "bar"}', 'lax $ .foo') or
json_exists ('{"foo": "bar"}', 'strict $ .foo')
Can we give a default mode to simplify the use of lax and strict. For
example, we default to lax mode. In this way, the use of our json function
can be simplified to:
json_exists ('{"foo": "bar"}', '$ .foo')
Implementation idea improvement JsonFunctions jsonApiCommonSyntax path
judgment to increase the default lax mode logic.
Of course, these changes are not described in SQL2016-2017.
I want to hear your opinion here.

[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=141724550
[2]
https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip

Re: [ANNOUNCE] New committer: Feng Zhu

[Forward Xu]

Congratulations！


Best，

Forward

Julian Hyde  于2020年3月1日周日 上午7:33写道：

> PS This is the “powered by” page:
> https://calcite.apache.org/docs/powered_by.html <
> https://calcite.apache.org/docs/powered_by.html>
>
> > On Feb 29, 2020, at 3:32 PM, Julian Hyde  wrote:
> >
> > Congratulations, thanks, and welcome!
> >
> > Feng, I wasn’t aware of Tencent’s SuperSQL project. It would be a great
> addition to the “powered by” page. If you would like to add it, please
> create a PR to add a paragraph to that page (no need for a JIRA case), and
> provide a link to a logo for Tencent that I can add to the picture.
> >
> > Julian
> >
> >
> >
> >> On Feb 29, 2020, at 3:15 PM, Rui Wang  wrote:
> >>
> >> Congratulations Feng! Well deserved!
> >>
> >>
> >>
> >> -Rui
> >>
> >> On Sat, Feb 29, 2020 at 2:10 AM Feng Zhu  wrote:
> >>
> >>> Thank you everyone for your warm welcome!
> >>> Currently I am working at SuperSQL team of Tencent in Shenzhen,
> Guangdong,
> >>> China.
> >>> The project relies heavily on Calcite to analyze data residing in
> thousands
> >>> of heterogeneous data sources.
> >>>
> >>> It is my greate honor to be part of the community. Calcite is an
> excellent
> >>> and promising project!
> >>> I will do my best to contribute to the project.
> >>>
> >>> Best regards,
> >>> Feng
> >>>
> >>> Chunwei Lei  于2020年2月29日周六 下午4:46写道：
> >>>
>  Congratulations！
> 
> 
>  Best,
>  Chunwei
> 
> 
>  On Sat, Feb 29, 2020 at 4:41 PM Danny Chan 
> wrote:
> 
> > Congratulations!
> >
> > Francis Chuang 于2020年2月29日 周六下午4:35写道：
> >
> >> Congrats, well-deserved!
> >>
> >> On 29/02/2020 6:26 pm, Stamatis Zampetakis wrote:
> >>> Apache Calcite's Project Management Committee (PMC) has invited
> >>> Feng
> >>> Zhu to become a committer, and we are pleased to announce that he
> >>> has accepted.
> >>>
> >>> Feng is an active contributor and has contributed a lot of code to
>  some
> >>> fairly complex parts of Calcite. He has been very helpful in
> > discussions
> >>> and reviews, especially around code generation, and his work is
>  always
> >>> of high quality.
> >>>
> >>> Feng, welcome, thank you for your contributions, and we look
> >>> forward
> >>> your further interactions with the community! If you wish, please
>  feel
> >>> free to tell us more about yourself and what you are working on.
> >>>
> >>> Stamatis (on behalf of the Apache Calcite PMC)
> >>>
> >>
> >
> 
> >>>
> >
>
>

Re: [DISCUSS] Towards Calcite 1.22.0

[Forward Xu]

Thanks, Danny.

+1


Best,

Forwardxu

Chunwei Lei  于2020年2月21日周五 上午8:51写道：

> Thanks, Danny.
>
> +1 to Danny’s timetable (RC on 2/24, release by 2/29).
>
>
> Best,
> Chunwei
>
>
> On Fri, Feb 21, 2020 at 2:37 AM Julian Hyde  wrote:
>
> > +1 to Danny’s timetable (RC on 2/24, release by 2/29).
> >
> > We can have a quick 1.23 (say 1 month after 1.22) if there are important
> > PRs that we don’t have time for this release. Of course we still have to
> > find reviewers for those PRs.
> >
> > Julian
> >
> >
> > > On Feb 19, 2020, at 11:18 PM, Danny Chan  wrote:
> > >
> > > Hi all,
> > >
> > > Approximately 5 months have passed from the previous release
> > > (Calcite 1.21.0) and I was thinking that it is the time to have the
> next
> > > release by the end of February. To do this I think we should try to
> have
> > an
> > > RC around the 24 of February(the next Monday).
> > >
> > > The progress towards the next release can be seen in [1].
> > > I have made some pre-edit of the issues, we do not have many issues
> > marked
> > > for fixing in version 1.22.0.
> > >
> > > Because it is a long-overdue, I would suggest we only concentrate on
> > > solving these issues in the following days,
> > > I’m not saying we are ignoring the existing PRs, but we did need a
> > release
> > > now that should happen 2 months ago.
> > >
> > > If you really think the issue/PR should be into release-1.22.0, please
> > > comment in this thread. I’m planning to pull the RC0 on
> > > 24 of February, thanks ~
> > >
> > > Don't hesitate to reply to this thread if the plan above is not
> > convenient
> > > for you!
> > >
> > > [1]
> > >
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > >
> > > Best,
> > > Danny Chan
> >
> >
>

Re: Contributors of 2019

[Forward Xu]

Hi Stamatis

Thank you very much.   I will also participate in the review later.

Best,
Forward

Forward Xu  于2020年1月12日周日 下午10:59写道：

> Hi Stamatis
>
> Thank you very much.
>
> Best,
> Forward
>
> Stamatis Zampetakis  于2020年1月12日周日 下午10:47写道：
>
>> Hi all,
>>
>> Looking back into 2019, I wanted to take a moment and thank all these
>> people who helped the project in one way or another. I know that stats do
>> not always tell the truth but it is a concrete measure that shows the
>> extraordinary effort of some people.
>>
>> Doing some post-processing on the commit logs (of Calcite & Avatica
>> master)
>> between Jan 2019 and Jan 2020, here what the numbers say:
>>
>> *Reviewers of the year*
>> Committer mail COUNTA of Review SUM of Lines modified
>> jh...@apache.org 60 20652
>> h.y...@alibaba-inc.com 79 8531
>> yuzhao@gmail.com 56 7004
>> mailto...@126.com 8 3736
>> zabe...@gmail.com 25 3465
>> michael.m...@gmail.com 16 3431
>> 25229979+asereda...@users.noreply.github.com 25 3353
>> rube...@gmail.com 9 2293
>> hon...@apache.org 13 2026
>> jcama...@apache.org 13 1293
>> sitnikov.vladi...@gmail.com 20 1049
>> vvo...@gmail.com 2 899
>> lauren...@users.noreply.github.com 6 867
>> mm...@cs.rit.edu 4 675
>> chun...@apache.org 10 674
>> laur...@dremio.com 3 668
>> els...@apache.org 3 610
>> francischu...@apache.org 6 324
>> kris...@apache.org 4 318
>> k...@rxd.hu 2 101
>> An vital part of every project is reviews. The people above have dedicated
>> a big part of their time reviewing and merging work of others. Looking
>> into
>> our backlog of PRs this is an area that we are a bit behind and we should
>> try to do better next year. Of course there are a few individuals (Julian,
>> Haisheng, Danny) who took on their shoulders a big burden and whom we
>> should try to imitate within our capacity.
>>
>> I would like also to mention that there are many people (committers & non
>> committers) who are helping a lot the project by reviewing PRs in GitHub.
>> Unfortunately, I didn't find an easy way to extract such stats from GitHub
>> to include them above.
>>
>> *Committers of the year*
>> Author mail SUM of Lines modified
>> COUNTA of Commit
>> sitnikov.vladi...@gmail.com 83780 97
>> jh...@apache.org 36662 63
>> yuzhao@gmail.com 22391 55
>> kht...@linkedin.com 7273 1
>> zabe...@gmail.com 7122 34
>> hon...@apache.org 5691 20
>> rube...@gmail.com 5475 30
>> chun...@apache.org 4341 27
>> x1q...@163.com 4210 15
>> jinxing.co...@gmail.com 3227 24
>> h.y...@alibaba-inc.com 3026 28
>> 1989yanlinw...@163.com 2562 15
>> j.feina...@pragmaticminds.de 2426 2
>> wellfeng...@gmail.com 1932 16
>> jcama...@apache.org 1711 12
>> vg...@apache.org 1630 11
>> ihor.huzenko@gmail.com 1545 5
>> 25229979+asereda...@users.noreply.github.com 1388 21
>> francischu...@apache.org 1355 35
>> yanzhi@antfin.com 1298 14
>> mouhoubi.kha...@gmail.com 1295 2
>> 953396...@qq.com 1061 10
>> shuo...@alibaba-inc.com 1051 4
>> ming...@ebay.com 1047 1
>> laur...@apache.org 1009 10
>> k...@rxd.hu 989 15
>> j...@dremio.com 909 5
>> wuchong...@alibaba-inc.com 818 1
>> vvo...@gmail.com 769 5
>> riteshkapoor.opensou...@gmail.com 747 4
>> hhlai1...@gmail.com 727 1
>> siddha...@dremio.com 705 3
>> absolute...@qq.com 685 1
>> prav...@dremio.com 650 1
>> wenhui_t...@yeah.net 646 8
>> m.gelb...@gmail.com 577 3
>> kris...@apache.org 558 13
>> mm...@cs.rit.edu 545 17
>> st...@stoty.hu 532 1
>> ming.moria...@gmail.com 488 4
>> chunwei...@163.com 406 2
>> bohdan.kazy...@gmail.com 404 2
>> cyazb...@murex.com 347 1
>> xndai@live.com 345 9
>> godfre...@163.com 321 3
>> shlok7...@github.com 320 1
>> ryan...@looker.com 320 3
>> lame...@users.noreply.github.com 316 4
>> chiboch...@gmail.com 299 1
>> zuoz...@gmail.com 279 1
>> yuzhao@alibaba-inc.com 246 1
>> amaliu...@163.com 227 6
>> wmy7...@gmail.com 201 3
>> krishnakant.agra...@datametica.com 199 2
>> 785294...@qq.com 193 1
>> dam6...@gmail.com 156 2
>> bot...@apache.org 154 2
>> snuyan...@gmail.com 139 3
>> nishant.mon...@gmail.com 129 1
>> chenghe...@gmail.com 124 1
>> weidong3...@126.com 120 2
>> wuchienc...@qq.com 118 2
>> b.hano...@criteo.com 116 1
>> justin.sw...@looker.com 104 1
>> whlwanghail...@didichuxing.com 103 1
>> asi...@maprtech.com 96 1
>> pengzhiwei2...@icloud.com 

Re: Contributors of 2019

[Forward Xu]

Hi Stamatis

Thank you very much.

Best,
Forward

Stamatis Zampetakis  于2020年1月12日周日 下午10:47写道：

> Hi all,
>
> Looking back into 2019, I wanted to take a moment and thank all these
> people who helped the project in one way or another. I know that stats do
> not always tell the truth but it is a concrete measure that shows the
> extraordinary effort of some people.
>
> Doing some post-processing on the commit logs (of Calcite & Avatica master)
> between Jan 2019 and Jan 2020, here what the numbers say:
>
> *Reviewers of the year*
> Committer mail COUNTA of Review SUM of Lines modified
> jh...@apache.org 60 20652
> h.y...@alibaba-inc.com 79 8531
> yuzhao@gmail.com 56 7004
> mailto...@126.com 8 3736
> zabe...@gmail.com 25 3465
> michael.m...@gmail.com 16 3431
> 25229979+asereda...@users.noreply.github.com 25 3353
> rube...@gmail.com 9 2293
> hon...@apache.org 13 2026
> jcama...@apache.org 13 1293
> sitnikov.vladi...@gmail.com 20 1049
> vvo...@gmail.com 2 899
> lauren...@users.noreply.github.com 6 867
> mm...@cs.rit.edu 4 675
> chun...@apache.org 10 674
> laur...@dremio.com 3 668
> els...@apache.org 3 610
> francischu...@apache.org 6 324
> kris...@apache.org 4 318
> k...@rxd.hu 2 101
> An vital part of every project is reviews. The people above have dedicated
> a big part of their time reviewing and merging work of others. Looking into
> our backlog of PRs this is an area that we are a bit behind and we should
> try to do better next year. Of course there are a few individuals (Julian,
> Haisheng, Danny) who took on their shoulders a big burden and whom we
> should try to imitate within our capacity.
>
> I would like also to mention that there are many people (committers & non
> committers) who are helping a lot the project by reviewing PRs in GitHub.
> Unfortunately, I didn't find an easy way to extract such stats from GitHub
> to include them above.
>
> *Committers of the year*
> Author mail SUM of Lines modified
> COUNTA of Commit
> sitnikov.vladi...@gmail.com 83780 97
> jh...@apache.org 36662 63
> yuzhao@gmail.com 22391 55
> kht...@linkedin.com 7273 1
> zabe...@gmail.com 7122 34
> hon...@apache.org 5691 20
> rube...@gmail.com 5475 30
> chun...@apache.org 4341 27
> x1q...@163.com 4210 15
> jinxing.co...@gmail.com 3227 24
> h.y...@alibaba-inc.com 3026 28
> 1989yanlinw...@163.com 2562 15
> j.feina...@pragmaticminds.de 2426 2
> wellfeng...@gmail.com 1932 16
> jcama...@apache.org 1711 12
> vg...@apache.org 1630 11
> ihor.huzenko@gmail.com 1545 5
> 25229979+asereda...@users.noreply.github.com 1388 21
> francischu...@apache.org 1355 35
> yanzhi@antfin.com 1298 14
> mouhoubi.kha...@gmail.com 1295 2
> 953396...@qq.com 1061 10
> shuo...@alibaba-inc.com 1051 4
> ming...@ebay.com 1047 1
> laur...@apache.org 1009 10
> k...@rxd.hu 989 15
> j...@dremio.com 909 5
> wuchong...@alibaba-inc.com 818 1
> vvo...@gmail.com 769 5
> riteshkapoor.opensou...@gmail.com 747 4
> hhlai1...@gmail.com 727 1
> siddha...@dremio.com 705 3
> absolute...@qq.com 685 1
> prav...@dremio.com 650 1
> wenhui_t...@yeah.net 646 8
> m.gelb...@gmail.com 577 3
> kris...@apache.org 558 13
> mm...@cs.rit.edu 545 17
> st...@stoty.hu 532 1
> ming.moria...@gmail.com 488 4
> chunwei...@163.com 406 2
> bohdan.kazy...@gmail.com 404 2
> cyazb...@murex.com 347 1
> xndai@live.com 345 9
> godfre...@163.com 321 3
> shlok7...@github.com 320 1
> ryan...@looker.com 320 3
> lame...@users.noreply.github.com 316 4
> chiboch...@gmail.com 299 1
> zuoz...@gmail.com 279 1
> yuzhao@alibaba-inc.com 246 1
> amaliu...@163.com 227 6
> wmy7...@gmail.com 201 3
> krishnakant.agra...@datametica.com 199 2
> 785294...@qq.com 193 1
> dam6...@gmail.com 156 2
> bot...@apache.org 154 2
> snuyan...@gmail.com 139 3
> nishant.mon...@gmail.com 129 1
> chenghe...@gmail.com 124 1
> weidong3...@126.com 120 2
> wuchienc...@qq.com 118 2
> b.hano...@criteo.com 116 1
> justin.sw...@looker.com 104 1
> whlwanghail...@didichuxing.com 103 1
> asi...@maprtech.com 96 1
> pengzhiwei2...@icloud.com 95 3
> ste...@looker.com 94 2
> stuti.gu...@datametica.com 92 1
> mel...@murex.com 90 1
> 1269223...@qq.com 90 2
> walter_...@hotmail.com 88 1
> justin.szel...@gmail.com 88 3
> hpe...@uber.com 88 1
> mail.mondal.s...@gmail.com 85 1
> doc...@gmail.com 79 2
> beyond1...@126.com 77 1
> 490081...@qq.com 76 2
> wellfeng...@tencent.com 73 1
> zhaindr...@hortonworks.com 72 1
> fudian...@alibaba-inc.com 62 1
> bake@alibaba-inc.com 59 1
> shikha.som...@servicesource.com 57 1
> laur...@dremio.com 53 1
> seancx...@gmail.com 48 2
> sahi...@spotify.com 47 1
> 9326...@gmail.com 37 1
> –fengfeng_...@163.com 32 1
> renhe@antfin.com 31 1
> els...@apache.org 31 6
> zhuan...@dragonsoft.com.cn 29 1
> divyansh...@datametica.com 29 1
> wuyunfen...@baidu.com 28 1
> hello...@gmail.com 28 1
> pressenna.sockalingas...@omnisci.com 26 1
> liusiyu...@360.cn 25 1
> li.x...@kyligence.io 25 1
> j...@apache.org 25 1
> 44845836+chad...@users.noreply.github.com 23 1
> zj48...@ly.com 19 1
> dijksp...@outlook.com 17 1

[jira] [Created] (CALCITE-3724) Implement PrestoSqlDialect

[Forward Xu (Jira)]

Forward Xu created CALCITE-3724:
---

 Summary: Implement PrestoSqlDialect
 Key: CALCITE-3724
 URL: https://issues.apache.org/jira/browse/CALCITE-3724
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


Implement PrestoSqlDialect



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

Re: [discuss] Implement Presto adapter

[Forward Xu]

Hi Julian,

In addition, we can also implement a PrestoSqlDialect.


Best,

Forward

Forward Xu  于2020年1月10日周五 下午2:23写道：

> Hi Julian,
>
> The current idea is through com.facebook.presto.spi.
> 1. Can be achieved through plugs provided by presto. For example [1].
> 2. You can construct Connector directly through
> com.facebook.presto.spi.ConnectorFactory [2].
>
> Best,
> Forward
>
> [1]
> https://www.codota.com/code/java/methods/com.facebook.presto.spi.Plugin/getConnectorFactories
> [2]
> https://www.programcreek.com/java-api-examples/?code=y-lan/presto/presto-master/presto-raptor/src/main/java/com/facebook/presto/raptor/RaptorPlugin.java
>
> Julian Hyde  于2020年1月10日周五 上午2:03写道：
>
>> Sounds like you are planning to target Presto’s internal engine rather
>> than Presto the database. To clarify, can you give an example of the code
>> that you would generate and send to Presto for a simple SQL query?
>>
>> Julian
>>
>>
>> > On Jan 9, 2020, at 5:07 AM, Forward Xu  wrote:
>> >
>> > Hi, Stamatis
>> >
>> > Because we have a number of internal clusters already using and
>> installing
>> > presto. And we want use calcite to optimize the parser and push it down
>> to
>> > presto, spark and other calculation engines or olaps. Utilize the sql
>> > optimization function of calite in combination with distributed
>> computing
>> > engines or distributed olaps such as presto. In this way, each
>> performance
>> > can be exerted.
>> >
>> > Best,
>> > Forward
>> >
>> > Stamatis Zampetakis  于2020年1月9日周四 下午8:51写道：
>> >
>> >> Hi,
>> >>
>> >> Presto seems to have many similarities with Calcite itself.
>> >> As you mentioned, Presto is not really a database but a distributed SQL
>> >> framework to query heterogeneous data sources.
>> >> Presto connectors are in some sense similar to Calcite adapters and if
>> the
>> >> Enumerable convention was capable of performing distributed joins etc.,
>> >> then the similarities would be even bigger.
>> >>
>> >> To the best of my knowledge, the majority of our users adopt Calcite
>> either
>> >> to query multiple data sources in a unified way or to provide SQL query
>> >> processing capabilities to data sources that do not already have.
>> Presto
>> >> seems to have similar goals, thus, I am not sure who will benefit from
>> this
>> >> new adapter.
>> >>
>> >> I never used Presto myself so I may have missed some important points.
>> Can
>> >> you share some use-cases about who may use this adapter and how?
>> >>
>> >> Best,
>> >> Stamatis
>> >>
>> >>
>> >> On Wed, Jan 8, 2020 at 2:44 PM Forward Xu 
>> wrote:
>> >>
>> >>> Hi everybody,
>> >>>
>> >>> I'd like to kick off a discussion on Implement Presto adapter in
>> calcite.
>> >>>
>> >>> We know that presto is also a powerful SQL query tool, which is widely
>> >> used
>> >>> with the olap of big data. So I want to add an adapter for presto to
>> >>> calite.
>> >>>
>> >>> Would love to hear your thoughts.
>> >>>
>> >>> Best,
>> >>> Forward
>> >>>
>> >>
>>
>>

Re: [discuss] Implement Presto adapter

[Forward Xu]

Hi Julian,

The current idea is through com.facebook.presto.spi.
1. Can be achieved through plugs provided by presto. For example [1].
2. You can construct Connector directly through
com.facebook.presto.spi.ConnectorFactory [2].

Best,
Forward

[1]
https://www.codota.com/code/java/methods/com.facebook.presto.spi.Plugin/getConnectorFactories
[2]
https://www.programcreek.com/java-api-examples/?code=y-lan/presto/presto-master/presto-raptor/src/main/java/com/facebook/presto/raptor/RaptorPlugin.java

Julian Hyde  于2020年1月10日周五 上午2:03写道：

> Sounds like you are planning to target Presto’s internal engine rather
> than Presto the database. To clarify, can you give an example of the code
> that you would generate and send to Presto for a simple SQL query?
>
> Julian
>
>
> > On Jan 9, 2020, at 5:07 AM, Forward Xu  wrote:
> >
> > Hi, Stamatis
> >
> > Because we have a number of internal clusters already using and
> installing
> > presto. And we want use calcite to optimize the parser and push it down
> to
> > presto, spark and other calculation engines or olaps. Utilize the sql
> > optimization function of calite in combination with distributed computing
> > engines or distributed olaps such as presto. In this way, each
> performance
> > can be exerted.
> >
> > Best,
> > Forward
> >
> > Stamatis Zampetakis  于2020年1月9日周四 下午8:51写道：
> >
> >> Hi,
> >>
> >> Presto seems to have many similarities with Calcite itself.
> >> As you mentioned, Presto is not really a database but a distributed SQL
> >> framework to query heterogeneous data sources.
> >> Presto connectors are in some sense similar to Calcite adapters and if
> the
> >> Enumerable convention was capable of performing distributed joins etc.,
> >> then the similarities would be even bigger.
> >>
> >> To the best of my knowledge, the majority of our users adopt Calcite
> either
> >> to query multiple data sources in a unified way or to provide SQL query
> >> processing capabilities to data sources that do not already have. Presto
> >> seems to have similar goals, thus, I am not sure who will benefit from
> this
> >> new adapter.
> >>
> >> I never used Presto myself so I may have missed some important points.
> Can
> >> you share some use-cases about who may use this adapter and how?
> >>
> >> Best,
> >> Stamatis
> >>
> >>
> >> On Wed, Jan 8, 2020 at 2:44 PM Forward Xu 
> wrote:
> >>
> >>> Hi everybody,
> >>>
> >>> I'd like to kick off a discussion on Implement Presto adapter in
> calcite.
> >>>
> >>> We know that presto is also a powerful SQL query tool, which is widely
> >> used
> >>> with the olap of big data. So I want to add an adapter for presto to
> >>> calite.
> >>>
> >>> Would love to hear your thoughts.
> >>>
> >>> Best,
> >>> Forward
> >>>
> >>
>
>

Re: [discuss] Implement Presto adapter

[Forward Xu]

Hi, Stamatis

Because we have a number of internal clusters already using and installing
presto. And we want use calcite to optimize the parser and push it down to
presto, spark and other calculation engines or olaps. Utilize the sql
optimization function of calite in combination with distributed computing
engines or distributed olaps such as presto. In this way, each performance
can be exerted.

Best,
Forward

Stamatis Zampetakis  于2020年1月9日周四 下午8:51写道：

> Hi,
>
> Presto seems to have many similarities with Calcite itself.
> As you mentioned, Presto is not really a database but a distributed SQL
> framework to query heterogeneous data sources.
> Presto connectors are in some sense similar to Calcite adapters and if the
> Enumerable convention was capable of performing distributed joins etc.,
> then the similarities would be even bigger.
>
> To the best of my knowledge, the majority of our users adopt Calcite either
> to query multiple data sources in a unified way or to provide SQL query
> processing capabilities to data sources that do not already have. Presto
> seems to have similar goals, thus, I am not sure who will benefit from this
> new adapter.
>
> I never used Presto myself so I may have missed some important points. Can
> you share some use-cases about who may use this adapter and how?
>
> Best,
> Stamatis
>
>
> On Wed, Jan 8, 2020 at 2:44 PM Forward Xu  wrote:
>
> > Hi everybody,
> >
> > I'd like to kick off a discussion on Implement Presto adapter in calcite.
> >
> > We know that presto is also a powerful SQL query tool, which is widely
> used
> > with the olap of big data. So I want to add an adapter for presto to
> > calite.
> >
> > Would love to hear your thoughts.
> >
> > Best,
> > Forward
> >
>

[discuss] Implement Presto adapter

[Forward Xu]

Hi everybody,

I'd like to kick off a discussion on Implement Presto adapter in calcite.

We know that presto is also a powerful SQL query tool, which is widely used
with the olap of big data. So I want to add an adapter for presto to calite.

Would love to hear your thoughts.

Best,
Forward

Re: Gradle documentation update

[Forward Xu]

OK, I can try to fix this.

Feng Zhu  于2020年1月7日周二 下午8:05写道：

> I also noticed the same problem several days ago when a colleague
> complained he failed to build Calcite according to the documents on
> website.
>
>
> E.g.,
>
> https://calcite.apache.org/docs/howto.html#building-from-a-source-distribution
>
>
>
>
>
>
>
>
> *$ git clone git://github.com/apache/calcite.git
> $ cd calcite$ ./mvnw install $ mvn
> clean$ mvn package... hacks ...$ mvn package -DskipGenerate*
>
> https://calcite.apache.org/develop/#download-source-build-and-run-tests
>
>
> *$ git clone git://github.com/apache/calcite.git
> $ cd calcite$ mvn install*
>
> Vladimir Sitnikov  于2020年1月7日周二 下午7:44写道：
>
> > Can you clarify an url which has stale information?
> >
> > Vladimir
> >
>

[discuss] Enhanced MATH Function

[Forward Xu]

Hi everybody,



I'd like to kick off a discussion on Enhanced MATH functions in calcite.



I recently checked java's math function and found that some functions in
calcite are not supported. So I made some comparisons with some commonly
used databases to discuss whether these functions need to be supported. The
comparison details are in [2]. And built an umbrella jira for this [1].



Would love to hear your thoughts.



Best,

Forward


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

[2]
https://docs.google.com/spreadsheets/d/1Q6Mj1ub-etyE0dbwvsaLquy6bz_fKuFX0vU3mGn8QKA/edit?usp=sharing

[jira] [Created] (CALCITE-3707) Implement COSH function

[Forward Xu (Jira)]

Forward Xu created CALCITE-3707:
---

 Summary: Implement COSH function
 Key: CALCITE-3707
 URL: https://issues.apache.org/jira/browse/CALCITE-3707
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


Implement COSH function.



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

[jira] [Created] (CALCITE-3706) IMPLEMENT POWEROFTWOF FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3706:
---

 Summary: IMPLEMENT POWEROFTWOF FUNCTION 
 Key: CALCITE-3706
 URL: https://issues.apache.org/jira/browse/CALCITE-3706
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT POWEROFTWOF FUNCTION



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

[jira] [Created] (CALCITE-3705) IMPLEMENT POWEROFTWOD FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3705:
---

 Summary: IMPLEMENT POWEROFTWOD FUNCTION
 Key: CALCITE-3705
 URL: https://issues.apache.org/jira/browse/CALCITE-3705
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT POWEROFTWOD FUNCTION



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

[jira] [Created] (CALCITE-3704) IMPLEMENT TWOTOTHEDOUBLESCALEDOWN FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3704:
---

 Summary: IMPLEMENT TWOTOTHEDOUBLESCALEDOWN FUNCTION
 Key: CALCITE-3704
 URL: https://issues.apache.org/jira/browse/CALCITE-3704
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT TWOTOTHEDOUBLESCALEDOWN FUNCTION



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

[jira] [Created] (CALCITE-3703) IMPLEMENT TWOTOTHEDOUBLESCALEUP FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3703:
---

 Summary: IMPLEMENT TWOTOTHEDOUBLESCALEUP FUNCTION
 Key: CALCITE-3703
 URL: https://issues.apache.org/jira/browse/CALCITE-3703
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT TWOTOTHEDOUBLESCALEUP FUNCTION



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

[jira] [Created] (CALCITE-3701) IMPLEMENT NEXTDOWN FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3701:
---

 Summary: IMPLEMENT NEXTDOWN FUNCTION
 Key: CALCITE-3701
 URL: https://issues.apache.org/jira/browse/CALCITE-3701
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT NEXTDOWN FUNCTION



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

[jira] [Created] (CALCITE-3702) IMPLEMENT SCALB FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3702:
---

 Summary: IMPLEMENT SCALB FUNCTION
 Key: CALCITE-3702
 URL: https://issues.apache.org/jira/browse/CALCITE-3702
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT SCALB FUNCTION



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

[jira] [Created] (CALCITE-3700) IMPLEMENT NEXTUP FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3700:
---

 Summary: IMPLEMENT NEXTUP FUNCTION
 Key: CALCITE-3700
 URL: https://issues.apache.org/jira/browse/CALCITE-3700
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT NEXTUP FUNCTION



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

[jira] [Created] (CALCITE-3699) IMPLEMENT NEXTAFTER FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3699:
---

 Summary: IMPLEMENT NEXTAFTER FUNCTION
 Key: CALCITE-3699
 URL: https://issues.apache.org/jira/browse/CALCITE-3699
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT NEXTAFTER FUNCTION



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

[jira] [Created] (CALCITE-3698) IMPLEMENT GETEXPONENT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3698:
---

 Summary: IMPLEMENT GETEXPONENT FUNCTION
 Key: CALCITE-3698
 URL: https://issues.apache.org/jira/browse/CALCITE-3698
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT GETEXPONENT FUNCTION



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

[jira] [Created] (CALCITE-3696) IMPLEMENT HYPOT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3696:
---

 Summary: IMPLEMENT HYPOT FUNCTION
 Key: CALCITE-3696
 URL: https://issues.apache.org/jira/browse/CALCITE-3696
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT HYPOT FUNCTION



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

[jira] [Created] (CALCITE-3697) IMPLEMENT COPYSIGN FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3697:
---

 Summary: IMPLEMENT COPYSIGN FUNCTION
 Key: CALCITE-3697
 URL: https://issues.apache.org/jira/browse/CALCITE-3697
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT COPYSIGN FUNCTION



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

[jira] [Created] (CALCITE-3695) IMPLEMENT TANH FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3695:
---

 Summary: IMPLEMENT TANH FUNCTION
 Key: CALCITE-3695
 URL: https://issues.apache.org/jira/browse/CALCITE-3695
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT TANH FUNCTION



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

[jira] [Created] (CALCITE-3694) IMPLEMENT SINH FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3694:
---

 Summary: IMPLEMENT SINH FUNCTION
 Key: CALCITE-3694
 URL: https://issues.apache.org/jira/browse/CALCITE-3694
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT SINH FUNCTION



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

[jira] [Created] (CALCITE-3693) IMPLEMENT ULP FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3693:
---

 Summary: IMPLEMENT ULP FUNCTION
 Key: CALCITE-3693
 URL: https://issues.apache.org/jira/browse/CALCITE-3693
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT ULP FUNCTION



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

[jira] [Created] (CALCITE-3691) IMPLEMENT NEGATEEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3691:
---

 Summary: IMPLEMENT NEGATEEXACT FUNCTION
 Key: CALCITE-3691
 URL: https://issues.apache.org/jira/browse/CALCITE-3691
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT NEGATEEXACT FUNCTION



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

[jira] [Created] (CALCITE-3692) IMPLEMENT TOINTEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3692:
---

 Summary: IMPLEMENT TOINTEXACT FUNCTION
 Key: CALCITE-3692
 URL: https://issues.apache.org/jira/browse/CALCITE-3692
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT TOINTEXACT FUNCTION



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

[jira] [Created] (CALCITE-3690) IMPLEMENT DECREMENTEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3690:
---

 Summary: IMPLEMENT DECREMENTEXACT FUNCTION
 Key: CALCITE-3690
 URL: https://issues.apache.org/jira/browse/CALCITE-3690
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT DECREMENTEXACT FUNCTION



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

[jira] [Created] (CALCITE-3689) IMPLEMENT INCREMENTEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3689:
---

 Summary: IMPLEMENT INCREMENTEXACT FUNCTION
 Key: CALCITE-3689
 URL: https://issues.apache.org/jira/browse/CALCITE-3689
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT INCREMENTEXACT FUNCTION



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

[jira] [Created] (CALCITE-3688) IMPLEMENT MULTIPLYEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3688:
---

 Summary: IMPLEMENT MULTIPLYEXACT FUNCTION
 Key: CALCITE-3688
 URL: https://issues.apache.org/jira/browse/CALCITE-3688
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT MULTIPLYEXACT FUNCTION



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

[jira] [Created] (CALCITE-3687) IMPLEMENT SUBTRACTEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3687:
---

 Summary: IMPLEMENT SUBTRACTEXACT FUNCTION
 Key: CALCITE-3687
 URL: https://issues.apache.org/jira/browse/CALCITE-3687
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT SUBTRACTEXACT FUNCTION



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

[jira] [Created] (CALCITE-3686) IMPLEMENT ADDEXACT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3686:
---

 Summary: IMPLEMENT ADDEXACT FUNCTION
 Key: CALCITE-3686
 URL: https://issues.apache.org/jira/browse/CALCITE-3686
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT ADDEXACT FUNCTION



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

[jira] [Created] (CALCITE-3685) IMPLEMENT RINT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3685:
---

 Summary: IMPLEMENT RINT FUNCTION
 Key: CALCITE-3685
 URL: https://issues.apache.org/jira/browse/CALCITE-3685
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT RINT FUNCTION



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

[jira] [Created] (CALCITE-3684) IMPLEMENT CBRT FUNCTION

[Forward Xu (Jira)]

Forward Xu created CALCITE-3684:
---

 Summary: IMPLEMENT CBRT FUNCTION
 Key: CALCITE-3684
 URL: https://issues.apache.org/jira/browse/CALCITE-3684
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu
Assignee: Forward Xu


IMPLEMENT CBRT FUNCTION.



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

[jira] [Created] (CALCITE-3683) Enhanced MATH Function

[Forward Xu (Jira)]

Forward Xu created CALCITE-3683:
---

 Summary: Enhanced MATH Function
 Key: CALCITE-3683
 URL: https://issues.apache.org/jira/browse/CALCITE-3683
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Forward Xu






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

[jira] [Created] (CALCITE-3642) Update cassandra tests upgrade from junit4 to junit5

[Forward Xu (Jira)]

Forward Xu created CALCITE-3642:
---

 Summary: Update cassandra tests upgrade from junit4 to junit5
 Key: CALCITE-3642
 URL: https://issues.apache.org/jira/browse/CALCITE-3642
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu


Update `Cassandra` tests upgrade from junit4 to junit5



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

[jira] [Created] (CALCITE-3637) Update linq4j tests upgrade from junit4 to junit5

[Forward Xu (Jira)]

Forward Xu created CALCITE-3637:
---

 Summary: Update linq4j tests upgrade from junit4 to junit5
 Key: CALCITE-3637
 URL: https://issues.apache.org/jira/browse/CALCITE-3637
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu


Update `linq4j` tests upgrade from junit4 to junit5



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

[jira] [Created] (CALCITE-3625) Update linq4j tests upgrade from junit4 to junit5

[Forward Xu (Jira)]

Forward Xu created CALCITE-3625:
---

 Summary: Update linq4j tests upgrade from junit4 to junit5
 Key: CALCITE-3625
 URL: https://issues.apache.org/jira/browse/CALCITE-3625
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu


Update `linq4j` tests upgrade from junit4 to junit5



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

[jira] [Created] (CALCITE-3622) Update geode tests upgrade from junit4 to junit5

[Forward Xu (Jira)]

Forward Xu created CALCITE-3622:
---

 Summary: Update geode tests upgrade from junit4 to junit5
 Key: CALCITE-3622
 URL: https://issues.apache.org/jira/browse/CALCITE-3622
 Project: Calcite
  Issue Type: Improvement
Reporter: Forward Xu


Update `geode` tests upgrade from junit4 to junit5.



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

[jira] [Created] (CALCITE-3601) Update cassandra, elasticsearch, geode, linq4j, mongodb test upgrade from junit4 to junit5

[Forward Xu (Jira)]

Forward Xu created CALCITE-3601:
---

 Summary: Update cassandra, elasticsearch, geode, linq4j, mongodb 
test upgrade from junit4 to junit5
 Key: CALCITE-3601
 URL: https://issues.apache.org/jira/browse/CALCITE-3601
 Project: Calcite
  Issue Type: Test
Reporter: Forward Xu


Update `cassandra, elasticsearch, geode, linq4j, and mongodb` tests upgrade 
from junit4 to junit5.



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

[jira] [Created] (CALCITE-3510) Implement sqlquery for Redis adapter

[Forward Xu (Jira)]

Forward Xu created CALCITE-3510:
---

 Summary: 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


sqlline> select * from "csv_02";
++---+
| DEPTNO | NAME |
++---+
| 20 | Sales |
| 10 | Sales |
++---+
2 rows selected (0.014 seconds)



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

[jira] [Created] (CALCITE-3329) Implement osquery command for OS adapter

[Forward Xu (Jira)]

Forward Xu created CALCITE-3329:
---

 Summary: Implement osquery command for OS adapter
 Key: CALCITE-3329
 URL: https://issues.apache.org/jira/browse/CALCITE-3329
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


Implement osquery command for OS adapter



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (CALCITE-3204) Implement jps command for OS adapter

[Forward Xu (JIRA)]

Forward Xu created CALCITE-3204:
---

 Summary: Implement jps command for OS adapter
 Key: CALCITE-3204
 URL: https://issues.apache.org/jira/browse/CALCITE-3204
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


Implement jps command for OS adapter



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (CALCITE-3176) File adapter for parsing JSON files

[Forward Xu (JIRA)]

Forward Xu created CALCITE-3176:
---

 Summary: 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


File adapter for parsing JSON files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-3139) Implement JSON_EXTRACT function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-3139:
---

 Summary: Implement JSON_EXTRACT function
 Key: CALCITE-3139
 URL: https://issues.apache.org/jira/browse/CALCITE-3139
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


[{{JSON_EXTRACT(_{{json_doc}}_, _{{path}}_[, _{{path}}_] 
...)}}|https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#function_json-extract]

Returns data from a JSON document, selected from the parts of the document 
matched by the _{{path}}_ arguments. Returns {{NULL}} if any argument is 
{{NULL}} or no paths locate a value in the document. An error occurs if the 
_{{json_doc}}_ argument is not a valid JSON document or any _{{path}}_ argument 
is not a valid path expression.

The return value consists of all values matched by the _{{path}}_ arguments. If 
it is possible that those arguments could return multiple values, the matched 
values are autowrapped as an array, in the order corresponding to the paths 
that produced them. Otherwise, the return value is the single matched value.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-3130) Implement JSON_UNQUOTE, JSON_QUOTE

[Forward Xu (JIRA)]

Forward Xu created CALCITE-3130:
---

 Summary: Implement JSON_UNQUOTE, JSON_QUOTE
 Key: CALCITE-3130
 URL: https://issues.apache.org/jira/browse/CALCITE-3130
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-3005) Implement string functions: LEFT, RIGHT

[Forward Xu (JIRA)]

Forward Xu created CALCITE-3005:
---

 Summary: Implement string functions: LEFT, RIGHT
 Key: CALCITE-3005
 URL: https://issues.apache.org/jira/browse/CALCITE-3005
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2995) Add the DAYNAME，MONTHNAME function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2995:
---

 Summary: Add the DAYNAME，MONTHNAME function
 Key: CALCITE-2995
 URL: https://issues.apache.org/jira/browse/CALCITE-2995
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


MONTHNAME(date)
 Returns the full name of the month for date. The language used for the name is 
controlled by the value of the lc_time_names system variable.

SQL:
{code:java}
SELECT MONTHNAME('2018-01-01') monthname;{code}
Result:
||monthname||
|January|

DAYNAME(date)
 Returns the name of the weekday for date. The language used for the name is 
controlled by the value of the lc_time_names system variable.

SQL:
{code:java}
SELECT DAYNAME('2018-01-01') dayname;{code}
Result:
||dayname||
|Monday|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2985) Add the JSON_STORAGE_SIZE function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2985:
---

 Summary: Add the JSON_STORAGE_SIZE function
 Key: CALCITE-2985
 URL: https://issues.apache.org/jira/browse/CALCITE-2985
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


JSON_STORAGE_SIZE(json_val)

This function returns the number of bytes used to store the binary 
representation of a JSON document. When the argument is a JSON column, this is 
the space used to store the JSON document. json_val must be a valid JSON 
document or a string which can be parsed as one. In the case where it is 
string, the function returns the amount of storage space in the JSON binary 
representation that is created by parsing the string as JSON and converting it 
to binary. It returns NULL if the argument is NULL.

An error results when json_val is not NULL, and is not—or cannot be 
successfully parsed as—a JSON document.

To illustrate this function's behavior when used with a JSON column as its 
argument, we create a table named jtable containing a JSON column jcol, insert 
a JSON value into the table, then obtain the storage space used by this column 
with JSON_STORAGE_SIZE(), as shown here:



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2984) Add the JSON_STORAGE_SIZE function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2984:
---

 Summary: Add the JSON_STORAGE_SIZE function
 Key: CALCITE-2984
 URL: https://issues.apache.org/jira/browse/CALCITE-2984
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


JSON_STORAGE_SIZE(json_val)

This function returns the number of bytes used to store the binary 
representation of a JSON document. When the argument is a JSON column, this is 
the space used to store the JSON document. json_val must be a valid JSON 
document or a string which can be parsed as one. In the case where it is 
string, the function returns the amount of storage space in the JSON binary 
representation that is created by parsing the string as JSON and converting it 
to binary. It returns NULL if the argument is NULL.

An error results when json_val is not NULL, and is not—or cannot be 
successfully parsed as—a JSON document.

To illustrate this function's behavior when used with a JSON column as its 
argument, we create a table named jtable containing a JSON column jcol, insert 
a JSON value into the table, then obtain the storage space used by this column 
with JSON_STORAGE_SIZE(), as shown here:



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2975) Add the JSON_REMOVE function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2975:
---

 Summary: Add the JSON_REMOVE function
 Key: CALCITE-2975
 URL: https://issues.apache.org/jira/browse/CALCITE-2975
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


JSON_REMOVE(json_doc, path[, path] ...)

Removes data from a JSON document and returns the result. Returns NULL if any 
argument is NULL. An error occurs if the json_doc argument is not a valid JSON 
document or any path argument is not a valid path expression or is $ or 
contains a * or ** wildcard.

The path arguments are evaluated left to right. The document produced by 
evaluating one path becomes the new value against which the next path is 
evaluated.

It is not an error if the element to be removed does not exist in the document; 
in that case, the path does not affect the document.
JSON_REMOVE SQL:

{code:java}
SELECT JSON_REMOVE(v, '$[1]') AS c1
 FROM (VALUES ('["a", ["b", "c"], "d"]')) AS t(v);
{code}

RESULT:

||c1||
|["a", "d"]|






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2892) Add the JSON_KEYS function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2892:
---

 Summary: Add the JSON_KEYS function
 Key: CALCITE-2892
 URL: https://issues.apache.org/jira/browse/CALCITE-2892
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


[{{JSON_KEYS(_{{json_doc}}_[, 
_{{path}}_])}}|https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-keys]

Returns the keys from the top-level value of a JSON object as a JSON array, or, 
if a _{{path}}_ argument is given, the top-level keys from the selected path. 
Returns {{NULL}} if any argument is {{NULL}}, the _{{json_doc}}_ argument is 
not an object, or _{{path}}_, if given, does not locate an object. An error 
occurs if the _{{json_doc}}_argument is not a valid JSON document or the 
_{{path}}_ argument is not a valid path expression or contains a {{*}} or 
{{**}} wildcard.

The result array is empty if the selected object is empty. If the top-level 
value has nested subobjects, the return value does not include keys from those 
subobjects.

Example SQL:
{code:java}
// code placeholder
SELECT JSON_KEYS(v) AS c1
,JSON_KEYS(v, 'lax $.a') AS c2
,JSON_KEYS(v, '$.b') AS c3
,JSON_KEYS(v, 'strict $.a[0]') AS c4
,JSON_KEYS(v, 'strict $.a[1]') AS c5
FROM (VALUES ('{"a": [10, true],"b": {"c": 30}}')) AS t(v)
LIMIT 10;
{code}
Result:
||c1||c2||c3||c4||c5||
|["a", "b"]|[NULL]|["c"]|[NULL]|[NULL]|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2884) Add the JSON_INSERT function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2884:
---

 Summary: Add the JSON_INSERT function
 Key: CALCITE-2884
 URL: https://issues.apache.org/jira/browse/CALCITE-2884
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


Inserts data into a JSON document and returns the result. Returns {{NULL}} if 
any argument is {{NULL}}. An error occurs if the _{{json_doc}}_ argument is not 
a valid JSON document or any _{{path}}_ argument is not a valid path expression 
or contains a {{*}} or {{**}} wildcard.

The path-value pairs are evaluated left to right. The document produced by 
evaluating one pair becomes the new value against which the next pair is 
evaluated.

A path-value pair for an existing path in the document is ignored and does not 
overwrite the existing document value. A path-value pair for a nonexisting path 
in the document adds the value to the document if the path identifies one of 
these types of values:
 * A member not present in an existing object. The member is added to the 
object and associated with the new value.

 * A position past the end of an existing array. The array is extended with the 
new value. If the existing value is not an array, it is autowrapped as an 
array, then extended with the new value.

Otherwise, a path-value pair for a nonexisting path in the document is ignored 
and has no effect.

For a comparison of 
[{{JSON_INSERT()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-insert],
 
[{{JSON_REPLACE()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-replace],
 and 
[{{JSON_SET()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set],
 see the discussion of 
[{{JSON_SET()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set].

Example SQL:

SELECT JSON_INSERT(v, '$.a', 10, '$.c', '[true, false]') AS c1
FROM (VALUES ('\{ "a": 1, "b": [2, 3]}')) AS t(v);

Result:

 
||c1||
|{"a": 1, "b": [2, 3], "c": "[true, false]"}|

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2864) Add the JSON_DEPTH function

[Forward Xu (JIRA)]

Forward Xu created CALCITE-2864:
---

 Summary: Add the JSON_DEPTH function
 Key: CALCITE-2864
 URL: https://issues.apache.org/jira/browse/CALCITE-2864
 Project: Calcite
  Issue Type: New Feature
Reporter: Forward Xu


Returns the maximum depth of a JSON document. Returns {{NULL}} if the argument 
is {{NULL}}. An error occurs if the argument is not a valid JSON document.

An empty array, empty object, or scalar value has depth 1. A nonempty array 
containing only elements of depth 1 or nonempty object containing only member 
values of depth 1 has depth 2. Otherwise, a JSON document has depth greater 
than 2.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)