Re: [DISCUSS] Towards Calcite 1.23.0
Hi, Haisheng, I would like to review the PR for CALCITE-3896. Best, Chunwei On Wed, May 6, 2020 at 4:50 AM Rui Wang wrote: > Thanks for leading 1.23.0 release, Haisheng! > > I will actively contact Danny and Feng to see if we can reach a conclusion > on https://github.com/apache/calcite/pull/1761 by next monday. > > > -Rui > > On Tue, May 5, 2020 at 11:31 AM Haisheng Yuan wrote: > > > Yes, no problem. Will have a RC before next Monday, PDT. > > > > @Roman, thanks for helping. > > This is the PR: https://github.com/apache/calcite/pull/1953 > > > > Haisheng > > > > On 2020/05/05 14:57:48, Julian Hyde wrote: > > > Thanks for volunteering, Haisheng. > > > > > > Before everyone piles in with wish-lists, can we set a timescale for > the > > release? > > > > > > I would suggest an aggressive timescale, for example an RC a week from > > today. Hold the RC only for mandatory cases. Other stuff gets in if it’s > > ready. > > > > > > Julian > > > > > > > On May 5, 2020, at 5:51 AM, Ruben Q L wrote: > > > > > > > > Thanks for starting the discussion, Stamatis. > > > > > > > > Just a reminder that there is a blocking issue [1] that needs to be > > solved > > > > (it is a regression introduced after 1.22). > > > > Apart from that, it would be nice if we could include [2] in 1.23. > > > > > > > > Best regards, > > > > Ruben > > > > > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3926 > > > > [2] https://issues.apache.org/jira/browse/CALCITE-3951 > > > > > > > > > > > > > > > >> Le mar. 5 mai 2020 à 12:34, Roman Kondakov > > > a > > > >> écrit : > > > >> > > > >> Hi Haisheng, > > > >> > > > >> I would like to review CALCITE-3896. Do you have a PR? > > > >> > > > >> > > > >> -- > > > >> Kind Regards > > > >> Roman Kondakov > > > >> > > > >> > > > >>> On 05.05.2020 06:37, Haisheng Yuan wrote: > > > >>> IIRC, I am the release manager for 1.23.0. > > > >>> > > > >>> I think CALCITE-3896 (top-down trait request) is in good shape, it > > will > > > >> be nice if it can go into 1.23.0. Can someone help review? > > > >>> > > > >>> On 2020/05/04 22:58:25, Stamatis Zampetakis > > wrote: > > > Hello, > > > > > > Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). > > > >> During > > > the vote we said to try to have a release sooner than usual so I > am > > > launching the discussion now hoping we could get to 1.23.0 rather > > soon. > > > > > > I was checking the status of the current release [1] and we have > > already > > > over 100 resolved issues with 91 fixes so it is already pretty > big. > > > > > > I know that there quite a few discussions in progress so it would > be > > > >> good > > > to see how many of the ongoing cases should be fixed for 1.23.0. > > > > > > More importantly do we have a release manager for 1.23.0? > > > > > > Best, > > > Stamatis > > > > > > [1] > > > > > > >> > > > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 > > > > > > >> > > > > > >
[jira] [Created] (CALCITE-3973) Writing SQL hints to a string results in SQL that cannot be parsed
Alex Baden created CALCITE-3973:
---
Summary: Writing SQL hints to a string results in SQL that cannot
be parsed
Key: CALCITE-3973
URL: https://issues.apache.org/jira/browse/CALCITE-3973
Project: Calcite
Issue Type: Bug
Reporter: Alex Baden
When using the new SQL hints feature:
{code:java}
select /*+ cpu */ x from test limit 2;
{code}
If one calls to SqlString() on the node:
{code:java}
node.toSqlString(CalciteSqlDialect.DEFAULT).toString()
{code}
We get:
{code:java}
'SELECT /*+ ("cpu") */ "x" FROM "test" FETCH NEXT 2 ROWS ONLY'
{code}
{{which is not valid SQL for a hint. It looks like the precedence options need
to be modified when writing out the hint in SqlSelectOperator.unparse}}
We do some rewriting of the sql statement and then re-parse it, so this is
preventing us from using hints. I am happy to submit a patch if I am headed in
the right direction with the description above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3972) Allow RelBuilder to create RelNode with convention and use it for trait convert
Xiening Dai created CALCITE-3972: Summary: Allow RelBuilder to create RelNode with convention and use it for trait convert Key: CALCITE-3972 URL: https://issues.apache.org/jira/browse/CALCITE-3972 Project: Calcite Issue Type: Bug Reporter: Xiening Dai 1. Provide Convention.transformRelBuilder() to transform an existing RelBuilder into one with specific convention. 2. RelBuilder provides withRelFactories() method to allow caller swap the underlying RelFactories and create a new builder. 3. Use the new interface in RelCollationTraitDef for converting into RelCollation traits We can avoid ~1/3 of total rule firings in a N way join case with this change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Towards Calcite 1.23.0
Thanks for leading 1.23.0 release, Haisheng! I will actively contact Danny and Feng to see if we can reach a conclusion on https://github.com/apache/calcite/pull/1761 by next monday. -Rui On Tue, May 5, 2020 at 11:31 AM Haisheng Yuan wrote: > Yes, no problem. Will have a RC before next Monday, PDT. > > @Roman, thanks for helping. > This is the PR: https://github.com/apache/calcite/pull/1953 > > Haisheng > > On 2020/05/05 14:57:48, Julian Hyde wrote: > > Thanks for volunteering, Haisheng. > > > > Before everyone piles in with wish-lists, can we set a timescale for the > release? > > > > I would suggest an aggressive timescale, for example an RC a week from > today. Hold the RC only for mandatory cases. Other stuff gets in if it’s > ready. > > > > Julian > > > > > On May 5, 2020, at 5:51 AM, Ruben Q L wrote: > > > > > > Thanks for starting the discussion, Stamatis. > > > > > > Just a reminder that there is a blocking issue [1] that needs to be > solved > > > (it is a regression introduced after 1.22). > > > Apart from that, it would be nice if we could include [2] in 1.23. > > > > > > Best regards, > > > Ruben > > > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3926 > > > [2] https://issues.apache.org/jira/browse/CALCITE-3951 > > > > > > > > > > > >> Le mar. 5 mai 2020 à 12:34, Roman Kondakov > a > > >> écrit : > > >> > > >> Hi Haisheng, > > >> > > >> I would like to review CALCITE-3896. Do you have a PR? > > >> > > >> > > >> -- > > >> Kind Regards > > >> Roman Kondakov > > >> > > >> > > >>> On 05.05.2020 06:37, Haisheng Yuan wrote: > > >>> IIRC, I am the release manager for 1.23.0. > > >>> > > >>> I think CALCITE-3896 (top-down trait request) is in good shape, it > will > > >> be nice if it can go into 1.23.0. Can someone help review? > > >>> > > >>> On 2020/05/04 22:58:25, Stamatis Zampetakis > wrote: > > Hello, > > > > Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). > > >> During > > the vote we said to try to have a release sooner than usual so I am > > launching the discussion now hoping we could get to 1.23.0 rather > soon. > > > > I was checking the status of the current release [1] and we have > already > > over 100 resolved issues with 91 fixes so it is already pretty big. > > > > I know that there quite a few discussions in progress so it would be > > >> good > > to see how many of the ongoing cases should be fixed for 1.23.0. > > > > More importantly do we have a release manager for 1.23.0? > > > > Best, > > Stamatis > > > > [1] > > > > >> > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 > > > > >> > > >
Re: [DISCUSS] Towards Calcite 1.23.0
Yes, no problem. Will have a RC before next Monday, PDT. @Roman, thanks for helping. This is the PR: https://github.com/apache/calcite/pull/1953 Haisheng On 2020/05/05 14:57:48, Julian Hyde wrote: > Thanks for volunteering, Haisheng. > > Before everyone piles in with wish-lists, can we set a timescale for the > release? > > I would suggest an aggressive timescale, for example an RC a week from today. > Hold the RC only for mandatory cases. Other stuff gets in if it’s ready. > > Julian > > > On May 5, 2020, at 5:51 AM, Ruben Q L wrote: > > > > Thanks for starting the discussion, Stamatis. > > > > Just a reminder that there is a blocking issue [1] that needs to be solved > > (it is a regression introduced after 1.22). > > Apart from that, it would be nice if we could include [2] in 1.23. > > > > Best regards, > > Ruben > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3926 > > [2] https://issues.apache.org/jira/browse/CALCITE-3951 > > > > > > > >> Le mar. 5 mai 2020 à 12:34, Roman Kondakov a > >> écrit : > >> > >> Hi Haisheng, > >> > >> I would like to review CALCITE-3896. Do you have a PR? > >> > >> > >> -- > >> Kind Regards > >> Roman Kondakov > >> > >> > >>> On 05.05.2020 06:37, Haisheng Yuan wrote: > >>> IIRC, I am the release manager for 1.23.0. > >>> > >>> I think CALCITE-3896 (top-down trait request) is in good shape, it will > >> be nice if it can go into 1.23.0. Can someone help review? > >>> > >>> On 2020/05/04 22:58:25, Stamatis Zampetakis wrote: > Hello, > > Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). > >> During > the vote we said to try to have a release sooner than usual so I am > launching the discussion now hoping we could get to 1.23.0 rather soon. > > I was checking the status of the current release [1] and we have already > over 100 resolved issues with 91 fixes so it is already pretty big. > > I know that there quite a few discussions in progress so it would be > >> good > to see how many of the ongoing cases should be fixed for 1.23.0. > > More importantly do we have a release manager for 1.23.0? > > Best, > Stamatis > > [1] > > >> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 > > >> >
Re: [DISCUSS] Towards Calcite 1.23.0
Thanks for volunteering, Haisheng. Before everyone piles in with wish-lists, can we set a timescale for the release? I would suggest an aggressive timescale, for example an RC a week from today. Hold the RC only for mandatory cases. Other stuff gets in if it’s ready. Julian > On May 5, 2020, at 5:51 AM, Ruben Q L wrote: > > Thanks for starting the discussion, Stamatis. > > Just a reminder that there is a blocking issue [1] that needs to be solved > (it is a regression introduced after 1.22). > Apart from that, it would be nice if we could include [2] in 1.23. > > Best regards, > Ruben > > [1] https://issues.apache.org/jira/browse/CALCITE-3926 > [2] https://issues.apache.org/jira/browse/CALCITE-3951 > > > >> Le mar. 5 mai 2020 à 12:34, Roman Kondakov a >> écrit : >> >> Hi Haisheng, >> >> I would like to review CALCITE-3896. Do you have a PR? >> >> >> -- >> Kind Regards >> Roman Kondakov >> >> >>> On 05.05.2020 06:37, Haisheng Yuan wrote: >>> IIRC, I am the release manager for 1.23.0. >>> >>> I think CALCITE-3896 (top-down trait request) is in good shape, it will >> be nice if it can go into 1.23.0. Can someone help review? >>> >>> On 2020/05/04 22:58:25, Stamatis Zampetakis wrote: Hello, Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). >> During the vote we said to try to have a release sooner than usual so I am launching the discussion now hoping we could get to 1.23.0 rather soon. I was checking the status of the current release [1] and we have already over 100 resolved issues with 91 fixes so it is already pretty big. I know that there quite a few discussions in progress so it would be >> good to see how many of the ongoing cases should be fixed for 1.23.0. More importantly do we have a release manager for 1.23.0? Best, Stamatis [1] >> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 >>
Re: Advise on ClassCastException in Linq4j$EnumeratorIterator
To repeat. In Enumerable convention, a SQL TIMESTAMP value must be represented
as a Java Long value.
Julian
PS Please subscribe to the dev list, to avoid moderation delays. And do not
email issues@; it is only for automatically generated emails.
> On May 5, 2020, at 7:22 AM, Ayelet Morris
> wrote:
>
> Sorry about the last email, it was a bit early...
> I found the exact location of the exception, in the current() method you
> can see the wrong cast:
> DateTimeUtils.floorDiv(*(Long) current[8]*, 8640L))
>
> As I explained earlier, the type of the field is TIMESTAMP, and it cannot
> be cast to long this way...
>
> please advise
>
>> On Tue, May 5, 2020 at 7:27 AM Ayelet Morris
>> wrote:
>>
>> + Calcite support mailing list.
>>
>> Hi again,
>>
>> I didn't receive any response from you guys, but I continued to debug this
>> today and managed to print the generated code and I saw a weird casting
>> that might explain what happens there:
>> public Object current() {
>> final Object[] current = (Object[])
>> inputEnumerator.current();
>> return* (java.sql.Timestamp) *current[8] == null ?* (Long)*
>> null :
>> *Long.valueOf*(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.DAY,
>> org.apache.calcite.avatica.util.DateTimeUtils.floorDiv((Long) current[8],
>> 8640L)));
>> }
>>
>> public Class getElementType() {
>> return *java.lang.Long.class*;
>> }
>>
>>
>> I marked in *bold* the interesting casting that happens there that I need
>> your help understanding:
>> it seems that the code casts the value into long and then re-casts it to
>> timestamp only to return as long, as you can see the element type is marked
>> as long...
>> Do you know why the generated code was generated this way? the field is
>> TIMESTAMP and the return value from the SQL function should be long...
>>
>> Hope you are all well.
>> Thanks!
>> Ayelet
>>
>> On Mon, Apr 27, 2020 at 4:49 PM Ayelet Morris <
>> ayelet.mor...@gigaspaces.com> wrote:
>>
>>> Hi Calcite Developers,
>>> Hope you are all doing well at this crazy time.
>>>
>>> I have a question regarding Linq4j$EnumeratorIterator
>>> throwing ClassCastException.
>>> *Background*: I'm running a Tableau testing framework called TDVT (it's
>>> in beta) in order to test our product's JDBC connector. Our product uses
>>> Calcite 1.21.0 and Avatics 1.15.0.
>>>
>>> I encountered this class cast exception when running timestamp related
>>> sql functions (I have about 127 different SQLs failing with the same class
>>> cast exception).
>>> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
>>> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV
>>> I'm using to fill in the POJO is written like this: '2004-07-23 21:13:37'
>>> *The exception:*
>>> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
>>> at Baz$1$1.current(Unknown Source)
>>> at
>>> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
>>> at
>>> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
>>> at
>>> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
>>> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
>>>
>>> This exception is thrown when trying to perform "next()"
>>> I cannot debug the generated code... I just see it being thrown there.
>>>
>>> I looked into the generated code for performing this (and similar) sql
>>> function and couldn't find a specific time format that is required, but in
>>> the documentation I saw the use of java.sql.Date as the function type, I
>>> tried to run my test with Date field I have in my POJO and it did return a
>>> correct result.
>>> I suspect it might not be compatible with Timestamp data type, though I
>>> saw in your tests you do test with timestamp '2008-1-23 12:12:12', I
>>> didn't try to run the test in the DruidAdapter suite but I saw that you are
>>> using a timestamp based column there.
>>>
>>> Do you know of a reason for this exception at this location? Did you see
>>> this exception before at this location? Do you have any idea where I should
>>> look for further information/clues?
>>>
>>> Thanks,
>>> Ayelet
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Re: Advise on ClassCastException in Linq4j$EnumeratorIterator
+ Calcite support mailing list.
Hi again,
I didn't receive any response from you guys, but I continued to debug this
today and managed to print the generated code and I saw a weird casting
that might explain what happens there:
public Object current() {
final Object[] current = (Object[]) inputEnumerator.current();
return* (java.sql.Timestamp) *current[8] == null ?* (Long)*
null :
*Long.valueOf*(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.DAY,
org.apache.calcite.avatica.util.DateTimeUtils.floorDiv((Long) current[8],
8640L)));
}
public Class getElementType() {
return *java.lang.Long.class*;
}
I marked in *bold* the interesting casting that happens there that I need
your help understanding:
it seems that the code casts the value into long and then re-casts it to
timestamp only to return as long, as you can see the element type is marked
as long...
Do you know why the generated code was generated this way? the field is
TIMESTAMP and the return value from the SQL function should be long...
Hope you are all well.
Thanks!
Ayelet
On Mon, Apr 27, 2020 at 4:49 PM Ayelet Morris
wrote:
> Hi Calcite Developers,
> Hope you are all doing well at this crazy time.
>
> I have a question regarding Linq4j$EnumeratorIterator
> throwing ClassCastException.
> *Background*: I'm running a Tableau testing framework called TDVT (it's
> in beta) in order to test our product's JDBC connector. Our product uses
> Calcite 1.21.0 and Avatics 1.15.0.
>
> I encountered this class cast exception when running timestamp related sql
> functions (I have about 127 different SQLs failing with the same class cast
> exception).
> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV
> I'm using to fill in the POJO is written like this: '2004-07-23 21:13:37'
> *The exception:*
> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
> at Baz$1$1.current(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
> at
> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at
> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
>
> This exception is thrown when trying to perform "next()"
> I cannot debug the generated code... I just see it being thrown there.
>
> I looked into the generated code for performing this (and similar) sql
> function and couldn't find a specific time format that is required, but in
> the documentation I saw the use of java.sql.Date as the function type, I
> tried to run my test with Date field I have in my POJO and it did return a
> correct result.
> I suspect it might not be compatible with Timestamp data type, though I
> saw in your tests you do test with timestamp '2008-1-23 12:12:12', I
> didn't try to run the test in the DruidAdapter suite but I saw that you are
> using a timestamp based column there.
>
> Do you know of a reason for this exception at this location? Did you see
> this exception before at this location? Do you have any idea where I should
> look for further information/clues?
>
> Thanks,
> Ayelet
>
>
>
>
>
>
>
>
>
Re: Advise on ClassCastException in Linq4j$EnumeratorIterator
Sorry about the last email, it was a bit early...
I found the exact location of the exception, in the current() method you
can see the wrong cast:
DateTimeUtils.floorDiv(*(Long) current[8]*, 8640L))
As I explained earlier, the type of the field is TIMESTAMP, and it cannot
be cast to long this way...
please advise
On Tue, May 5, 2020 at 7:27 AM Ayelet Morris
wrote:
> + Calcite support mailing list.
>
> Hi again,
>
> I didn't receive any response from you guys, but I continued to debug this
> today and managed to print the generated code and I saw a weird casting
> that might explain what happens there:
> public Object current() {
> final Object[] current = (Object[])
> inputEnumerator.current();
> return* (java.sql.Timestamp) *current[8] == null ?* (Long)*
> null :
> *Long.valueOf*(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.DAY,
> org.apache.calcite.avatica.util.DateTimeUtils.floorDiv((Long) current[8],
> 8640L)));
> }
>
> public Class getElementType() {
>return *java.lang.Long.class*;
> }
>
>
> I marked in *bold* the interesting casting that happens there that I need
> your help understanding:
> it seems that the code casts the value into long and then re-casts it to
> timestamp only to return as long, as you can see the element type is marked
> as long...
> Do you know why the generated code was generated this way? the field is
> TIMESTAMP and the return value from the SQL function should be long...
>
> Hope you are all well.
> Thanks!
> Ayelet
>
> On Mon, Apr 27, 2020 at 4:49 PM Ayelet Morris <
> ayelet.mor...@gigaspaces.com> wrote:
>
>> Hi Calcite Developers,
>> Hope you are all doing well at this crazy time.
>>
>> I have a question regarding Linq4j$EnumeratorIterator
>> throwing ClassCastException.
>> *Background*: I'm running a Tableau testing framework called TDVT (it's
>> in beta) in order to test our product's JDBC connector. Our product uses
>> Calcite 1.21.0 and Avatics 1.15.0.
>>
>> I encountered this class cast exception when running timestamp related
>> sql functions (I have about 127 different SQLs failing with the same class
>> cast exception).
>> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
>> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV
>> I'm using to fill in the POJO is written like this: '2004-07-23 21:13:37'
>> *The exception:*
>> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
>> at Baz$1$1.current(Unknown Source)
>> at
>> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
>> at
>> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
>> at
>> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
>> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
>>
>> This exception is thrown when trying to perform "next()"
>> I cannot debug the generated code... I just see it being thrown there.
>>
>> I looked into the generated code for performing this (and similar) sql
>> function and couldn't find a specific time format that is required, but in
>> the documentation I saw the use of java.sql.Date as the function type, I
>> tried to run my test with Date field I have in my POJO and it did return a
>> correct result.
>> I suspect it might not be compatible with Timestamp data type, though I
>> saw in your tests you do test with timestamp '2008-1-23 12:12:12', I
>> didn't try to run the test in the DruidAdapter suite but I saw that you are
>> using a timestamp based column there.
>>
>> Do you know of a reason for this exception at this location? Did you see
>> this exception before at this location? Do you have any idea where I should
>> look for further information/clues?
>>
>> Thanks,
>> Ayelet
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: [DISCUSS] Towards Calcite 1.23.0
Thanks for starting the discussion, Stamatis. Just a reminder that there is a blocking issue [1] that needs to be solved (it is a regression introduced after 1.22). Apart from that, it would be nice if we could include [2] in 1.23. Best regards, Ruben [1] https://issues.apache.org/jira/browse/CALCITE-3926 [2] https://issues.apache.org/jira/browse/CALCITE-3951 Le mar. 5 mai 2020 à 12:34, Roman Kondakov a écrit : > Hi Haisheng, > > I would like to review CALCITE-3896. Do you have a PR? > > > -- > Kind Regards > Roman Kondakov > > > On 05.05.2020 06:37, Haisheng Yuan wrote: > > IIRC, I am the release manager for 1.23.0. > > > > I think CALCITE-3896 (top-down trait request) is in good shape, it will > be nice if it can go into 1.23.0. Can someone help review? > > > > On 2020/05/04 22:58:25, Stamatis Zampetakis wrote: > >> Hello, > >> > >> Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). > During > >> the vote we said to try to have a release sooner than usual so I am > >> launching the discussion now hoping we could get to 1.23.0 rather soon. > >> > >> I was checking the status of the current release [1] and we have already > >> over 100 resolved issues with 91 fixes so it is already pretty big. > >> > >> I know that there quite a few discussions in progress so it would be > good > >> to see how many of the ongoing cases should be fixed for 1.23.0. > >> > >> More importantly do we have a release manager for 1.23.0? > >> > >> Best, > >> Stamatis > >> > >> [1] > >> > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 > >> >
Re: [DISCUSS] Towards Calcite 1.23.0
Hi Haisheng, I would like to review CALCITE-3896. Do you have a PR? -- Kind Regards Roman Kondakov On 05.05.2020 06:37, Haisheng Yuan wrote: > IIRC, I am the release manager for 1.23.0. > > I think CALCITE-3896 (top-down trait request) is in good shape, it will be > nice if it can go into 1.23.0. Can someone help review? > > On 2020/05/04 22:58:25, Stamatis Zampetakis wrote: >> Hello, >> >> Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). During >> the vote we said to try to have a release sooner than usual so I am >> launching the discussion now hoping we could get to 1.23.0 rather soon. >> >> I was checking the status of the current release [1] and we have already >> over 100 resolved issues with 91 fixes so it is already pretty big. >> >> I know that there quite a few discussions in progress so it would be good >> to see how many of the ongoing cases should be fixed for 1.23.0. >> >> More importantly do we have a release manager for 1.23.0? >> >> Best, >> Stamatis >> >> [1] >> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 >>
