Re: Avatica maven

[Kevin Risden]

I was able to reproduce this and it looks like the root cause:

https://issues.apache.org/jira/browse/MNG-6300

Maven 3.5.3 fixes this. Maven 3.5.1 and 3.5.2 look to be the only versions
that have the offending Maven commit
(be223808939d75152d7157db33d45f230114555e) but no fix. Maven 3.5.0 works as
well.

Doesn't look like there is anything we can do to work around this from what
I can tell.

Kevin Risden

On Tue, May 29, 2018 at 5:19 PM, Julian Hyde  wrote:

> The symptoms look very much like this: https://github.com/travis-ci/
> travis-ci/issues/8499  >.
>
> If so, maven versions before 3.5.0 (e.g. 3.3.9) should be OK.
>
> Julian
>
>
> > On May 29, 2018, at 2:46 PM, Kevin Risden  wrote:
> >
> > Are they fixed in Maven proper or are we relying on a default Maven
> plugin
> > version that is failing?
> >
> > Maven 3.5.3 was released early in March. Seems weird to require such a
> > recent version.
> >
> > I can try to take a look tonight to see if I can reproduce.
> >
> > Kevin Risden
> >
> > On Tue, May 29, 2018, 16:43 Michael Mior  wrote:
> >
> >> Sounds like a good idea to me. Unfortunately, Ubuntu 18.04 (the current
> LTS
> >> release) is currently on Maven 3.5.2. Not much we can do about that
> though.
> >>
> >> --
> >> Michael Mior
> >> mm...@uwaterloo.ca
> >>
> >>
> >> Le mar. 29 mai 2018 à 17:24, Julian Hyde  a écrit :
> >>
> >>> I’ve run into problems building Avatica using maven-3.5.2 that are
> fixed
> >>> using maven-3.5.3. When executing “mvn clean install javadoc:javadoc
> >> site”
> >>> (on Ubuntu, on virtually any JDK version), I get
> >>>
> >>>  [ERROR] Failed to execute goal
> >>> org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on
> >> project
> >>> avatica-standalone-server: Error creating shaded jar:
> >>> /home/jhyde/regress/calcite-avatica/server/target/classes (Is a
> >> directory)
> >>> -> [Help 1]
> >>>
> >>> The currently recommended version is "3.2.1 or later” [1]. Any
> objections
> >>> if I change the recommended version to "3.5.3 or later”?
> >>>
> >>>
> >>> Julian
> >>>
> >>> [1] http://calcite.apache.org/avatica/develop/avatica.html <
> >>> http://calcite.apache.org/avatica/develop/avatica.html>
> >>
>
>

Re: RxNode (Filter) / Translator for various adapters (ES, Mongo, Geode etc.). Possible Bug ?

[Andrei Sereda]

Can somebody please give me a hint on why Mongo Translator

was
implemented the way it is now ? Ie why RexVisitor

is not being used to (recursively) translate RelNode into mongo query ?

Would like to take a stub at CALCITE-2331 but, before,  want to ensure I'm
not missing anything.

On Tue, May 29, 2018 at 7:20 AM, Andrei Sereda  wrote:

> Any reason why RexNode visitor API is not used for implementing Mongo
> query translator ?
>
> Looking at current source code (MongoFilter
> )
> it seems one expects certain order of conditions (eg. first AND then OR)
> which is not generic enough. Is it for operator precedence ?
>
>
>
> On Mon, May 28, 2018 at 11:20 PM, Andrei Sereda  wrote:
>
>> Yes seems like subtree is not visited recursively for OR opeator(s).
>>
>> I have added a test to track this issue: https://github.com/apac
>> he/calcite/pull/703
>>
>>
>>
>> On Mon, May 28, 2018 at 11:06 PM, liu xiaorui 
>> wrote:
>>
>>> I also encountered this problem .   After I debug the code I found the
>>> cause of the problem .  for example  condition is A AND (B OR C )   .
>>>
>>>  orNode is AND (A,OR (B,C))  and  then execute method translateAdd
>>> , condition A can  be translated successfully , and exception will be throw
>>> out when translating  condition  OR(B,C) .  so I think we can think
>>> about recursively.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 29 May 2018 at 09:56, Julian Hyde  wrote:
>>>
 Looks like a bug. I don't know that code well, so I can't speculate
 what might be the cause.

 Can you log a JIRA case please? If you can provide a unit test (say, a
 method to add to MongoAdapterIT) even better.

 On Mon, May 28, 2018 at 2:47 PM, Andrei Sereda 
 wrote:
 > Hello,
 >
 > Please correct me if my expectations are inaccurate about query
 predicates
 > in Calcite.
 >
 > I think there is an issue in how expression translators work when AST
 is
 > more complex (has more depth). Same code / logic is used across
 different
 > adapters (Mongo / Geode / ES) so multiple data-sources might be
 affected.
 >
 > Examples
 >
 > 1. Works
 >
 > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
 > "elastic" where _MAP['foo'] in ('1') and true;
 >
 > 2. Works
 > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
 > "elastic" where _MAP['foo'] ='1' and true;
 >
 > 3. Works
 > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
 > "elastic" where _MAP['foo'] in ('1', '2');
 >
 >
 > 4. Fails
 >
 > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
 > "elastic" where _MAP['foo'] in ('1', '2') and true;
 >
 >
 > 5. Fails
 >
 > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
 > "elastic" where true and _MAP['foo'] in ('1', '2');
 >
 >
 > 6. Fails
 >
 > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
 > "elastic" where (_MAP['foo'] ='1' or _MAP['foo'] = '2') and true;
 >
 >
 >
 > Exception Stack (Elastic Adapter)
 >
 >
 > java.lang.AssertionError: cannot translate OR(=(ITEM($0, 'foo'), '1'),
 > =(ITEM($0, 'foo'), '2'))
 >
 > at org.apache.calcite.adapter.ela
 sticsearch.ElasticsearchFilter$
 > Translator.translateMatch2(ElasticsearchFilter.java:234)
 >
 > at org.apache.calcite.adapter.ela
 sticsearch.ElasticsearchFilter$
 > Translator.translateAnd(ElasticsearchFilter.java:158)
 >
 > at org.apache.calcite.adapter.ela
 sticsearch.ElasticsearchFilter$
 > Translator.translateOr(ElasticsearchFilter.java:115)
 >
 > at org.apache.calcite.adapter.ela
 sticsearch.ElasticsearchFilter$
 > Translator.translateMatch(ElasticsearchFilter.java:101)
 >
 > at org.apache.calcite.adapter.ela
 sticsearch.ElasticsearchFilter$
 > Translator.access$000(ElasticsearchFilter.java:87)
 >
 > at org.apache.calcite.adapter.elasticsearch.
 > ElasticsearchFilter.implement(ElasticsearchFilter.java:80)
 >
 > at org.apache.calcite.adapter.elasticsearch.
 > ElasticsearchRel$Implementor.visitChild(ElasticsearchRel.java:53)
 >
 > at org.apache.calcite.adapter.elasticsearch.
 > ElasticsearchToEnumerableConverter.implement(ElasticsearchTo
 EnumerableConve
 > rter.java:71)
 >
 > at org.apache.calcite.adapter.enu
 merable.EnumerableRelImplementor.
 > 

Calcite-Master - Build # 289 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

[jira] [Created] (CALCITE-2335) Switch to vgo for dependency management

[Francis Chuang (JIRA)]

Francis Chuang created CALCITE-2335:
---

 Summary: Switch to vgo for dependency management
 Key: CALCITE-2335
 URL: https://issues.apache.org/jira/browse/CALCITE-2335
 Project: Calcite
  Issue Type: Task
  Components: avatica-go
Reporter: Francis Chuang
Assignee: Francis Chuang


The proposal for vgo has been accepted: 
[https://research.swtch.com/vgo-accepted]

vgo aims to replace dep for dependency management in Go.

TLDR; vgo will be part of the Go tool chain in Go 1.11 (July 31 2018) on an 
experimental basis. Official production-ready status will be in Go 1.12 
(January 2019).

We should remove dep and move to vgo when Go 1.11 is released so that we can 
work out any idiosyncrasies before Go 1.12.



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

Calcite-Master - Build # 288 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Calcite-Master - Build # 287 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

[jira] [Created] (CALCITE-2334) Extend simplification of expressions with CEIL function over date types

[Jesus Camacho Rodriguez (JIRA)]

Jesus Camacho Rodriguez created CALCITE-2334:


 Summary: Extend simplification of expressions with CEIL function 
over date types
 Key: CALCITE-2334
 URL: https://issues.apache.org/jira/browse/CALCITE-2334
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.17.0
Reporter: Jesus Camacho Rodriguez
Assignee: Julian Hyde


CALCITE-2332 disables simplification of CEIL function due to correctness issues.

{{FLOOR}} and {{CEIL}} cannot be handled with the same logic. For instance, 
{{CEIL(CEIL(x TO HOUR) TO YEAR)}} cannot be simplified, e.g., '2011-12-31 
23:59:59', while {{FLOOR(FLOOR(x TO HOUR) TO YEAR)}} can be simplified. Hence, 
we need new logic to enable simplification of CEIL function on date types.



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

Re: Does Calcite hold all records output from a node before passing them to a higher node ?

[Julian Hyde]

Yes, when you use a Sink there is an assumption that there is a Node running 
that is consuming from the deque. Currently the Interpreter only runs one Node 
at a time, which means that the full output of that Node sits in a deque for a 
while.

Clearly the Interpreter has much room for improvement.

> On May 29, 2018, at 3:22 PM, Muhammad Gelbana  wrote:
> 
> I found out what was consuming the memory and delaying the results at the
> same time. I was pushing all obtained rows from the datasource into a sink
> creating by this method
> .
> Pushing rows into the sink halts further nodes execution until all rows are
> totally loaded. I thought since the sink is backed by an "ArrayDeque" that
> the rows would be consumed while being pushed to the sink.
> 
> The other approach I applied was to use the "enumerable" method instead.
> This way, returned rows from my nodes are available for successive nodes
> without delay.
> 
> Thank you all and thank you Julian for the Arrow adapter code.
> 
> Thanks,
> Gelbana
> 
> On Tue, May 29, 2018 at 5:50 PM, Julian Hyde  wrote:
> 
>> I believe that scan, filter, project do not buffer; aggregate, join and
>> sort do buffer; join perhaps buffers a little more than it should.
>> 
>> Read methods in EnumerableDefaults, for example EnumerableDefaults.join,
>> to see where a blocking collection is created and from which input.
>> 
>> Ideally the operators would exploit sorted input (e.g. we could have an
>> aggregate that assumes input is sorted by the GROUP BY key and only buffers
>> records that have the same key) but Enumerable does not aim to be a
>> high-performance, scalable engine, so this never got prioritized.
>> 
>> On a related note, I was pleased to see progress on an Arrow adapter and
>> convention in https://issues.apache.org/jira/browse/CALCITE-2173 <
>> https://issues.apache.org/jira/browse/CALCITE-2173>. If we were to write
>> a high-performance engine that scales across many threads, it would be
>> based on Arrow. So anyone with complaints about the performance of
>> Enumerable convention should start contributing to Arrow convention!
>> 
>> Julian
>> 
>> 
>>> On May 29, 2018, at 7:20 AM, Michael Mior  wrote:
>>> 
>>> In theory it certainly should be possible to stream the results. This
>> isn't
>>> guaranteed however. You would have to look at the entire query pipeline
>> to
>>> see where things are being materialized. A full stack trace without
>>> elements removed would be a good start.
>>> 
>>> --
>>> Michael Mior
>>> mm...@apache.org
>>> 
>>> 
>>> 
>>> Le lun. 28 mai 2018 à 19:05, Muhammad Gelbana  a
>>> écrit :
>>> 
 I'm not sure if I phrased my question correctly so let me explain more.
 
 I'm running a (SELECT * FROM TABLE) query against a 50 million records
 table (Following the BINDABLE convention, so it sends it's rows through
>> a
 "sink"). Since the extracted rows aren't processed in any way, I was
 expecting that the output JDBC resultset would be able to enumerate
>> through
 all the results in a matter of seconds, but instead, my machine didn't
 print anything. What exactly happens is that
 (PreparedStatement.executeQuery) doesn't return a resultset promptly
>> even
 after a few minutes have passed.
 
 I tried a table with hundreds of rows and my testing code printed those
 results right away so it's not something I missed there, but probably a
 configuration I didn't set ? Or may be that's just how it is ? Does
>> anyone
 else believe that the behaviour I expected is reasonable ? It would also
 lower the amount of memory consumed to hold the complete results before
 bursting them to their final destination, if that's the case in the
>> first
 place.
 
 
 Thanks,
 Gelbana
 
>> 
>> 

Re: Best practice for exhaustive planning

[Kenneth Knowles]

Thanks Michael,

I don't think that applies in our case - we aren't doing a table scan and
having Calcite implement the rest, but are translating the whole plan to a
Beam pipeline to run on e.g. Flink, Spark, Dataflow.

Here's an example:

SELECT * FROM UNNEST (ARRAY ['a', 'b', 'c'])

With logical plan:

LogicalProject(EXPR$0=[$0])
  Uncollect
LogicalProject(EXPR$0=[ARRAY('a', 'b', 'c')])
  LogicalValues(tuples=[[{ 0 }]])

And the planner dumps "could not be implemented" when going for Beam's
calling convention. So I implement a rel & a rule.

Then there's the corellated version exploding an array field from a table:

SELECT f_int, arrElems.f_string FROM main CROSS JOIN UNNEST
(main.f_stringArr) AS arrElems(f_string)

With logical plan:

LogicalProject(f_int=[$0], f_string=[$2])
  LogicalCorrelate(correlation=[$cor0], joinType=[inner],
requiredColumns=[{1}])
BeamIOSourceRel(table=[[beam, main]])
Uncollect
  LogicalProject(f_stringArr=[$cor0.f_stringArr_1])
LogicalValues(tuples=[[{ 0 }]])

I hacked something together to support this, too. I did not fully implement
Correlate; I would love to reject unsupported things in a meaningful way. I
would like to have confidence that there are not other permutations of
logical plans that we missed. For example for joins we match all joins and
translate them, then throw an error at a later stage.

Incidentally, when I ran the decorrelation [1] it appeared to have no
effect. We probably want to implement it directly in Beam anyhow in this
case.

Kenn

[1]
https://calcite.apache.org/apidocs/org/apache/calcite/sql2rel/SqlToRelConverter.html#decorrelate-org.apache.calcite.sql.SqlNode-org.apache.calcite.rel.RelNode-

On Tue, May 22, 2018 at 6:39 PM Michael Mior  wrote:

> For most queries, the only thing you should need to implement is a scan and
> the rest can usually be implemented by Calcite. It would be good if you
> have a specific example of a query that fails.
>
> --
> Michael Mior
> mm...@uwaterloo.ca
>
>
> Le mar. 22 mai 2018 à 19:01, Kenneth Knowles  a
> écrit :
>
> > Bumping this, as it ended up in spam for some people.
> >
> > Kenn
> >
> > On Tue, May 15, 2018 at 9:26 AM Kenneth Knowles  wrote:
> >
> > > Hi all,
> > >
> > > Beam SQL uses Calcite for parsing and (naive) planning. Currently it is
> > > pretty easy to write a SQL query that parses and causes a "could not
> > plan"
> > > dump when we ask the planner to convert things to the Beam calling
> > > convention. One current example is using UNNEST on a column to yield a
> > > LogicalCorrelate + Uncollect.
> > >
> > > There may obviously always be bits we don't support, but we'd like to
> > > ensure that the user encounters a careful error message rather than a
> > > planner dump. Is there a best practice for ensuring that we have
> covered
> > > all the cases? Is it just "everything name Logical*" or is there
> > something
> > > more clever?
> > >
> > > And if this question demonstrates that we are using Calcite entirely
> > > wrong, let us know :-)
> > >
> > > Kenn
> > >
> >
>

Re: Does Calcite hold all records output from a node before passing them to a higher node ?

[Muhammad Gelbana]

I found out what was consuming the memory and delaying the results at the
same time. I was pushing all obtained rows from the datasource into a sink
creating by this method
.
Pushing rows into the sink halts further nodes execution until all rows are
totally loaded. I thought since the sink is backed by an "ArrayDeque" that
the rows would be consumed while being pushed to the sink.

The other approach I applied was to use the "enumerable" method instead.
This way, returned rows from my nodes are available for successive nodes
without delay.

Thank you all and thank you Julian for the Arrow adapter code.

Thanks,
Gelbana

On Tue, May 29, 2018 at 5:50 PM, Julian Hyde  wrote:

> I believe that scan, filter, project do not buffer; aggregate, join and
> sort do buffer; join perhaps buffers a little more than it should.
>
> Read methods in EnumerableDefaults, for example EnumerableDefaults.join,
> to see where a blocking collection is created and from which input.
>
> Ideally the operators would exploit sorted input (e.g. we could have an
> aggregate that assumes input is sorted by the GROUP BY key and only buffers
> records that have the same key) but Enumerable does not aim to be a
> high-performance, scalable engine, so this never got prioritized.
>
> On a related note, I was pleased to see progress on an Arrow adapter and
> convention in https://issues.apache.org/jira/browse/CALCITE-2173 <
> https://issues.apache.org/jira/browse/CALCITE-2173>. If we were to write
> a high-performance engine that scales across many threads, it would be
> based on Arrow. So anyone with complaints about the performance of
> Enumerable convention should start contributing to Arrow convention!
>
> Julian
>
>
> > On May 29, 2018, at 7:20 AM, Michael Mior  wrote:
> >
> > In theory it certainly should be possible to stream the results. This
> isn't
> > guaranteed however. You would have to look at the entire query pipeline
> to
> > see where things are being materialized. A full stack trace without
> > elements removed would be a good start.
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> >
> >
> > Le lun. 28 mai 2018 à 19:05, Muhammad Gelbana  a
> > écrit :
> >
> >> I'm not sure if I phrased my question correctly so let me explain more.
> >>
> >> I'm running a (SELECT * FROM TABLE) query against a 50 million records
> >> table (Following the BINDABLE convention, so it sends it's rows through
> a
> >> "sink"). Since the extracted rows aren't processed in any way, I was
> >> expecting that the output JDBC resultset would be able to enumerate
> through
> >> all the results in a matter of seconds, but instead, my machine didn't
> >> print anything. What exactly happens is that
> >> (PreparedStatement.executeQuery) doesn't return a resultset promptly
> even
> >> after a few minutes have passed.
> >>
> >> I tried a table with hundreds of rows and my testing code printed those
> >> results right away so it's not something I missed there, but probably a
> >> configuration I didn't set ? Or may be that's just how it is ? Does
> anyone
> >> else believe that the behaviour I expected is reasonable ? It would also
> >> lower the amount of memory consumed to hold the complete results before
> >> bursting them to their final destination, if that's the case in the
> first
> >> place.
> >>
> >>
> >> Thanks,
> >> Gelbana
> >>
>
>

Re: Avatica maven

[Julian Hyde]

The symptoms look very much like this: 
https://github.com/travis-ci/travis-ci/issues/8499 
.

If so, maven versions before 3.5.0 (e.g. 3.3.9) should be OK.

Julian


> On May 29, 2018, at 2:46 PM, Kevin Risden  wrote:
> 
> Are they fixed in Maven proper or are we relying on a default Maven plugin
> version that is failing?
> 
> Maven 3.5.3 was released early in March. Seems weird to require such a
> recent version.
> 
> I can try to take a look tonight to see if I can reproduce.
> 
> Kevin Risden
> 
> On Tue, May 29, 2018, 16:43 Michael Mior  wrote:
> 
>> Sounds like a good idea to me. Unfortunately, Ubuntu 18.04 (the current LTS
>> release) is currently on Maven 3.5.2. Not much we can do about that though.
>> 
>> --
>> Michael Mior
>> mm...@uwaterloo.ca
>> 
>> 
>> Le mar. 29 mai 2018 à 17:24, Julian Hyde  a écrit :
>> 
>>> I’ve run into problems building Avatica using maven-3.5.2 that are fixed
>>> using maven-3.5.3. When executing “mvn clean install javadoc:javadoc
>> site”
>>> (on Ubuntu, on virtually any JDK version), I get
>>> 
>>>  [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on
>> project
>>> avatica-standalone-server: Error creating shaded jar:
>>> /home/jhyde/regress/calcite-avatica/server/target/classes (Is a
>> directory)
>>> -> [Help 1]
>>> 
>>> The currently recommended version is "3.2.1 or later” [1]. Any objections
>>> if I change the recommended version to "3.5.3 or later”?
>>> 
>>> 
>>> Julian
>>> 
>>> [1] http://calcite.apache.org/avatica/develop/avatica.html <
>>> http://calcite.apache.org/avatica/develop/avatica.html>
>> 

Calcite Avatica Travis job failed with connection timeout to repo.maven.apache.org

[Sergey Nuyanzin]

Hello

One of the travis jobs (others are success) failed with timeout like

Connect to repo.maven.apache.org:443
[repo.maven.apache.org/151.101.44.215] failed: Connection timed out
(Connection timed out)

based on logs there is

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T19:49:05Z)

Java version: 11, vendor: Oracle Corporation

I guess only jdk version differs among all the jobs
Could anyone please tell how to cope with it?

failed travis job https://travis-ci.org/apache/c
alcite-avatica/jobs/385394507



-- 
Best regards,
Sergey

Re: [DISCUSS] Towards Avatica 1.12.0

[Laurent Goujon]

I'll try to wrap up CALCITE-2219 asap. At the same time, I can also help
reviewing CALCITE-1884, CALCITE-2322 and CALCITE-2303.

On Tue, May 29, 2018 at 12:51 PM, Julian Hyde  wrote:

> Thanks, that’s a good list.
>
> I’m glad you listed 1884 and 2303. I will make sure those get in.
>
> In https://issues.apache.org/jira/browse/CALCITE-2272 <
> https://issues.apache.org/jira/browse/CALCITE-2272> Kevin updated our
> dependencies (java source 1.8, apache parent pom 19), but if anyone wants
> to upgrade any of our other dependencies, now is the time to consider it.
>
> Julian
>
>
> > On May 29, 2018, at 1:37 AM, Francis Chuang 
> wrote:
> >
> > Avatica 1.11.0 was released on March 6 (more than 3 months ago). We
> should discuss the next release (1.12.0).
> >
> > The current consensus is to have a release in around 2 weeks.
> >
> > The JIRA tracking the release is CALCITE-2330 [1].
> >
> > As the release cycle for this would is a bit short, I think it would be
> a good idea to focus our efforts on low hanging fruit, bugs and
> features/enhancements that won't take a lot of time (unless someone is able
> to dedicate significant resources).
> >
> > Personally, I would love to see the following fixed:
> >
> > CALCITE-1951 [2]: Avatica with HSQLDB loses fractional seconds. Kevin
> and Josh has done some investigation, so I hope this is a relatively simple
> fix. Test is here: https://github.com/apache/calcite-avatica/pull/36
> >
> > CALCITE-2250 [3]: Avatica with HSQLDB hangs when using multiple
> transactions. Kevin has done some investigation and the issue is easily
> reproducible.
> >
> > CALCITE-2219 [4]: Acvtica Connection/Statement/ResultSet don't throw if
> resource is closed. Work has started: https://github.com/apache/
> calcite-avatica/pull/33
> >
> > CALCITE-2333 [5]: Stop releasing ZIPs. Assigned to myself.
> >
> > Nice to haves:
> >
> > CALCITE-1049 [7]: SQLException not correctly propagated. This is
> preventing clients from taking different actions when they encounter
> different SQLExceptions. However, the fix might not be too simple.
> >
> > I'd also like to use this release to clean up the PRs on Github:
> >
> > CALCITE-1884 [8]: DateTimeUtils produces incorrect results for days
> before Gregorian cutovers. https://github.com/apache/
> calcite-avatica/pull/11 The PR is almost a year old. Can someone please
> take a look at this so we can merge or close it?
> >
> > CALCITE-2294 [9]: Allow customization for plugging in new authentication
> mechanisms. Is active and will be in this release:
> https://github.com/apache/calcite-avatica/pull/48
> >
> > CALCITE-2322 [10]: Add fetch size support to connection URL and JDBC
> state. Seems to be implemented, can someone please review?
> https://github.com/apache/calcite-avatica/pull/49
> >
> > CALCITE-2303 [11]: Support extraction of microseconds, milliseconds,
> epoch, isodow, isoyear and decade. Can someone please review?
> https://github.com/apache/calcite-avatica/pull/50
> >
> > Are there any other features or bugs people would like implemented or
> fixed?
> >
> > Francis
> >
> > [1] https://issues.apache.org/jira/browse/CALCITE-2330
> >
> > [2] https://issues.apache.org/jira/browse/CALCITE-1951
> >
> > [3] https://issues.apache.org/jira/browse/CALCITE-2250
> >
> > [4] https://issues.apache.org/jira/browse/CALCITE-2219
> >
> > [5] https://issues.apache.org/jira/browse/CALCITE-2333
> >
> > [6] https://issues.apache.org/jira/browse/CALCITE-1049
> >
> > [7] https://issues.apache.org/jira/browse/CALCITE-1049
> >
> > [8] https://issues.apache.org/jira/browse/CALCITE-1884
> >
> > [9] https://issues.apache.org/jira/browse/CALCITE-2294
> >
> > [10] https://issues.apache.org/jira/browse/CALCITE-2322
> >
> > [11] https://issues.apache.org/jira/browse/CALCITE-2303
> >
>
>

Calcite Avatica Travis job failed with connection timeout to repo.maven.apache.org

[Sergey Nuyanzin]

Hello

One of the travis jobs (others are success) failed with timeout like

Connect to repo.maven.apache.org:443
[repo.maven.apache.org/151.101.44.215] failed: Connection timed out
(Connection timed out)

based on logs there is

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T19:49:05Z)

Java version: 11, vendor: Oracle Corporation

I guess only jdk version differs among all the jobs
Could anyone please tell how to cope with it?

failed travis job
https://travis-ci.org/apache/calcite-avatica/jobs/385394507


-- 
Best regards,
Sergey

Re: Avatica maven

[Kevin Risden]

Are they fixed in Maven proper or are we relying on a default Maven plugin
version that is failing?

Maven 3.5.3 was released early in March. Seems weird to require such a
recent version.

I can try to take a look tonight to see if I can reproduce.

Kevin Risden

On Tue, May 29, 2018, 16:43 Michael Mior  wrote:

> Sounds like a good idea to me. Unfortunately, Ubuntu 18.04 (the current LTS
> release) is currently on Maven 3.5.2. Not much we can do about that though.
>
> --
> Michael Mior
> mm...@uwaterloo.ca
>
>
> Le mar. 29 mai 2018 à 17:24, Julian Hyde  a écrit :
>
> > I’ve run into problems building Avatica using maven-3.5.2 that are fixed
> > using maven-3.5.3. When executing “mvn clean install javadoc:javadoc
> site”
> > (on Ubuntu, on virtually any JDK version), I get
> >
> >   [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on
> project
> > avatica-standalone-server: Error creating shaded jar:
> > /home/jhyde/regress/calcite-avatica/server/target/classes (Is a
> directory)
> > -> [Help 1]
> >
> > The currently recommended version is "3.2.1 or later” [1]. Any objections
> > if I change the recommended version to "3.5.3 or later”?
> >
> >
> > Julian
> >
> > [1] http://calcite.apache.org/avatica/develop/avatica.html <
> > http://calcite.apache.org/avatica/develop/avatica.html>
>

Re: Avatica maven

[Michael Mior]

Sounds like a good idea to me. Unfortunately, Ubuntu 18.04 (the current LTS
release) is currently on Maven 3.5.2. Not much we can do about that though.

--
Michael Mior
mm...@uwaterloo.ca


Le mar. 29 mai 2018 à 17:24, Julian Hyde  a écrit :

> I’ve run into problems building Avatica using maven-3.5.2 that are fixed
> using maven-3.5.3. When executing “mvn clean install javadoc:javadoc site”
> (on Ubuntu, on virtually any JDK version), I get
>
>   [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on project
> avatica-standalone-server: Error creating shaded jar:
> /home/jhyde/regress/calcite-avatica/server/target/classes (Is a directory)
> -> [Help 1]
>
> The currently recommended version is "3.2.1 or later” [1]. Any objections
> if I change the recommended version to "3.5.3 or later”?
>
>
> Julian
>
> [1] http://calcite.apache.org/avatica/develop/avatica.html <
> http://calcite.apache.org/avatica/develop/avatica.html>

Avatica maven

[Julian Hyde]

I’ve run into problems building Avatica using maven-3.5.2 that are fixed using 
maven-3.5.3. When executing “mvn clean install javadoc:javadoc site” (on 
Ubuntu, on virtually any JDK version), I get 

  [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on project 
avatica-standalone-server: Error creating shaded jar: 
/home/jhyde/regress/calcite-avatica/server/target/classes (Is a directory) -> 
[Help 1]

The currently recommended version is "3.2.1 or later” [1]. Any objections if I 
change the recommended version to "3.5.3 or later”?


Julian

[1] http://calcite.apache.org/avatica/develop/avatica.html 

Re: [DISCUSS] Towards Avatica 1.12.0

[Julian Hyde]

Thanks, that’s a good list.

I’m glad you listed 1884 and 2303. I will make sure those get in.

In https://issues.apache.org/jira/browse/CALCITE-2272 
 Kevin updated our 
dependencies (java source 1.8, apache parent pom 19), but if anyone wants to 
upgrade any of our other dependencies, now is the time to consider it.

Julian


> On May 29, 2018, at 1:37 AM, Francis Chuang  wrote:
> 
> Avatica 1.11.0 was released on March 6 (more than 3 months ago). We should 
> discuss the next release (1.12.0).
> 
> The current consensus is to have a release in around 2 weeks.
> 
> The JIRA tracking the release is CALCITE-2330 [1].
> 
> As the release cycle for this would is a bit short, I think it would be a 
> good idea to focus our efforts on low hanging fruit, bugs and 
> features/enhancements that won't take a lot of time (unless someone is able 
> to dedicate significant resources).
> 
> Personally, I would love to see the following fixed:
> 
> CALCITE-1951 [2]: Avatica with HSQLDB loses fractional seconds. Kevin and 
> Josh has done some investigation, so I hope this is a relatively simple fix. 
> Test is here: https://github.com/apache/calcite-avatica/pull/36
> 
> CALCITE-2250 [3]: Avatica with HSQLDB hangs when using multiple transactions. 
> Kevin has done some investigation and the issue is easily reproducible.
> 
> CALCITE-2219 [4]: Acvtica Connection/Statement/ResultSet don't throw if 
> resource is closed. Work has started: 
> https://github.com/apache/calcite-avatica/pull/33
> 
> CALCITE-2333 [5]: Stop releasing ZIPs. Assigned to myself.
> 
> Nice to haves:
> 
> CALCITE-1049 [7]: SQLException not correctly propagated. This is preventing 
> clients from taking different actions when they encounter different 
> SQLExceptions. However, the fix might not be too simple.
> 
> I'd also like to use this release to clean up the PRs on Github:
> 
> CALCITE-1884 [8]: DateTimeUtils produces incorrect results for days before 
> Gregorian cutovers. https://github.com/apache/calcite-avatica/pull/11 The PR 
> is almost a year old. Can someone please take a look at this so we can merge 
> or close it?
> 
> CALCITE-2294 [9]: Allow customization for plugging in new authentication 
> mechanisms. Is active and will be in this release: 
> https://github.com/apache/calcite-avatica/pull/48
> 
> CALCITE-2322 [10]: Add fetch size support to connection URL and JDBC state. 
> Seems to be implemented, can someone please review? 
> https://github.com/apache/calcite-avatica/pull/49
> 
> CALCITE-2303 [11]: Support extraction of microseconds, milliseconds, epoch, 
> isodow, isoyear and decade. Can someone please review? 
> https://github.com/apache/calcite-avatica/pull/50
> 
> Are there any other features or bugs people would like implemented or fixed?
> 
> Francis
> 
> [1] https://issues.apache.org/jira/browse/CALCITE-2330
> 
> [2] https://issues.apache.org/jira/browse/CALCITE-1951
> 
> [3] https://issues.apache.org/jira/browse/CALCITE-2250
> 
> [4] https://issues.apache.org/jira/browse/CALCITE-2219
> 
> [5] https://issues.apache.org/jira/browse/CALCITE-2333
> 
> [6] https://issues.apache.org/jira/browse/CALCITE-1049
> 
> [7] https://issues.apache.org/jira/browse/CALCITE-1049
> 
> [8] https://issues.apache.org/jira/browse/CALCITE-1884
> 
> [9] https://issues.apache.org/jira/browse/CALCITE-2294
> 
> [10] https://issues.apache.org/jira/browse/CALCITE-2322
> 
> [11] https://issues.apache.org/jira/browse/CALCITE-2303
> 

Re: Testing expression (RexNode) transformations

[Michael Mior]

Looks awesome! Thanks Julian and Zoltan!
--
Michael Mior
mm...@apache.org



Le mar. 29 mai 2018 à 15:36, Julian Hyde  a écrit :

> With Zoltan’s help, I just committed [1] a nice change to RexSimplify,
> adding a “paranoid” flag. If you set paranoid = true, then RexSimplify will
> simplify expressions but it will also try to prove that the transformation
> is wrong. It does that by assigning sample values to variables and checking
> that the simplified expression produces the same result as the original
> expression.
>
> Consider the expression
>
>   (not a) and (b > 5) and (not true)
>
> This simplifies to “false”, because of the trailing “not true”. “a” is
> boolean, so we use sample values {unknown, false, true}; “b” is an integer,
> so we use values {null, 0, 1, 1,000,000}. For the 15 (3 x 5) combinations
> of assignments to variables (a, b), we evaluate the original expression and
> the simplified expression, and make sure they give the same result. If the
> result is different, we have proved that the simplification is invalid. I
> already found one bug [2] this way.
>
> I added RexInterpreter (which evaluates RexNode expressions by
> interpreting, rather than by generating Java as RexExecutor does) because I
> didn’t want to increase coupling.
>
> One area this could be improved is to add more values based on the
> expression. Because the integer literal 5 is present, we ought to check
> values {4, 5, 6} in addition to the default values {null, -1, 0, 1,
> 1,000,000}.
>
> It’s really important that our transformation rules can be trusted, so
> please use this functionality as much as you can in tests. If you your
> transformation does not use RexSimplify, you can use RexAnalyzer directly.
> Also, add more tests for rex transformations; each test gives RexSimplifier
> a lot of opportunities to find faults.
>
> Julian
>
> [1] https://issues.apache.org/jira/browse/CALCITE-2314 <
> https://issues.apache.org/jira/browse/CALCITE-2314>
>
> [2] https://issues.apache.org/jira/browse/CALCITE-2332 <
> https://issues.apache.org/jira/browse/CALCITE-2332>

Testing expression (RexNode) transformations

[Julian Hyde]

With Zoltan’s help, I just committed [1] a nice change to RexSimplify, adding a 
“paranoid” flag. If you set paranoid = true, then RexSimplify will simplify 
expressions but it will also try to prove that the transformation is wrong. It 
does that by assigning sample values to variables and checking that the 
simplified expression produces the same result as the original expression.

Consider the expression

  (not a) and (b > 5) and (not true)

This simplifies to “false”, because of the trailing “not true”. “a” is boolean, 
so we use sample values {unknown, false, true}; “b” is an integer, so we use 
values {null, 0, 1, 1,000,000}. For the 15 (3 x 5) combinations of assignments 
to variables (a, b), we evaluate the original expression and the simplified 
expression, and make sure they give the same result. If the result is 
different, we have proved that the simplification is invalid. I already found 
one bug [2] this way.

I added RexInterpreter (which evaluates RexNode expressions by interpreting, 
rather than by generating Java as RexExecutor does) because I didn’t want to 
increase coupling.

One area this could be improved is to add more values based on the expression. 
Because the integer literal 5 is present, we ought to check values {4, 5, 6} in 
addition to the default values {null, -1, 0, 1, 1,000,000}.

It’s really important that our transformation rules can be trusted, so please 
use this functionality as much as you can in tests. If you your transformation 
does not use RexSimplify, you can use RexAnalyzer directly. Also, add more 
tests for rex transformations; each test gives RexSimplifier a lot of 
opportunities to find faults.

Julian

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


[2] https://issues.apache.org/jira/browse/CALCITE-2332 
 

Re: Does Calcite hold all records output from a node before passing them to a higher node ?

[Julian Hyde]

I believe that scan, filter, project do not buffer; aggregate, join and sort do 
buffer; join perhaps buffers a little more than it should. 

Read methods in EnumerableDefaults, for example EnumerableDefaults.join, to see 
where a blocking collection is created and from which input.

Ideally the operators would exploit sorted input (e.g. we could have an 
aggregate that assumes input is sorted by the GROUP BY key and only buffers 
records that have the same key) but Enumerable does not aim to be a 
high-performance, scalable engine, so this never got prioritized.

On a related note, I was pleased to see progress on an Arrow adapter and 
convention in https://issues.apache.org/jira/browse/CALCITE-2173 
. If we were to write a 
high-performance engine that scales across many threads, it would be based on 
Arrow. So anyone with complaints about the performance of Enumerable convention 
should start contributing to Arrow convention!

Julian


> On May 29, 2018, at 7:20 AM, Michael Mior  wrote:
> 
> In theory it certainly should be possible to stream the results. This isn't
> guaranteed however. You would have to look at the entire query pipeline to
> see where things are being materialized. A full stack trace without
> elements removed would be a good start.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le lun. 28 mai 2018 à 19:05, Muhammad Gelbana  a
> écrit :
> 
>> I'm not sure if I phrased my question correctly so let me explain more.
>> 
>> I'm running a (SELECT * FROM TABLE) query against a 50 million records
>> table (Following the BINDABLE convention, so it sends it's rows through a
>> "sink"). Since the extracted rows aren't processed in any way, I was
>> expecting that the output JDBC resultset would be able to enumerate through
>> all the results in a matter of seconds, but instead, my machine didn't
>> print anything. What exactly happens is that
>> (PreparedStatement.executeQuery) doesn't return a resultset promptly even
>> after a few minutes have passed.
>> 
>> I tried a table with hundreds of rows and my testing code printed those
>> results right away so it's not something I missed there, but probably a
>> configuration I didn't set ? Or may be that's just how it is ? Does anyone
>> else believe that the behaviour I expected is reasonable ? It would also
>> lower the amount of memory consumed to hold the complete results before
>> bursting them to their final destination, if that's the case in the first
>> place.
>> 
>> 
>> Thanks,
>> Gelbana
>> 

Re: Does Calcite hold all records output from a node before passing them to a higher node ?

[Michael Mior]

In theory it certainly should be possible to stream the results. This isn't
guaranteed however. You would have to look at the entire query pipeline to
see where things are being materialized. A full stack trace without
elements removed would be a good start.

--
Michael Mior
mm...@apache.org



Le lun. 28 mai 2018 à 19:05, Muhammad Gelbana  a
écrit :

> I'm not sure if I phrased my question correctly so let me explain more.
>
> I'm running a (SELECT * FROM TABLE) query against a 50 million records
> table (Following the BINDABLE convention, so it sends it's rows through a
> "sink"). Since the extracted rows aren't processed in any way, I was
> expecting that the output JDBC resultset would be able to enumerate through
> all the results in a matter of seconds, but instead, my machine didn't
> print anything. What exactly happens is that
> (PreparedStatement.executeQuery) doesn't return a resultset promptly even
> after a few minutes have passed.
>
> I tried a table with hundreds of rows and my testing code printed those
> results right away so it's not something I missed there, but probably a
> configuration I didn't set ? Or may be that's just how it is ? Does anyone
> else believe that the behaviour I expected is reasonable ? It would also
> lower the amount of memory consumed to hold the complete results before
> bursting them to their final destination, if that's the case in the first
> place.
>
>
> Thanks,
> Gelbana
>

Calcite-Master - Build # 286 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Re: RxNode (Filter) / Translator for various adapters (ES, Mongo, Geode etc.). Possible Bug ?

[Andrei Sereda]

Any reason why RexNode visitor API is not used for implementing Mongo query
translator ?

Looking at current source code (MongoFilter
)
it seems one expects certain order of conditions (eg. first AND then OR)
which is not generic enough. Is it for operator precedence ?



On Mon, May 28, 2018 at 11:20 PM, Andrei Sereda  wrote:

> Yes seems like subtree is not visited recursively for OR opeator(s).
>
> I have added a test to track this issue: https://github.com/
> apache/calcite/pull/703
>
>
>
> On Mon, May 28, 2018 at 11:06 PM, liu xiaorui  wrote:
>
>> I also encountered this problem .   After I debug the code I found the
>> cause of the problem .  for example  condition is A AND (B OR C )   .
>>
>>  orNode is AND (A,OR (B,C))  and  then execute method translateAdd  ,
>> condition A can  be translated successfully , and exception will be throw
>> out when translating  condition  OR(B,C) .  so I think we can think
>> about recursively.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 29 May 2018 at 09:56, Julian Hyde  wrote:
>>
>>> Looks like a bug. I don't know that code well, so I can't speculate
>>> what might be the cause.
>>>
>>> Can you log a JIRA case please? If you can provide a unit test (say, a
>>> method to add to MongoAdapterIT) even better.
>>>
>>> On Mon, May 28, 2018 at 2:47 PM, Andrei Sereda  wrote:
>>> > Hello,
>>> >
>>> > Please correct me if my expectations are inaccurate about query
>>> predicates
>>> > in Calcite.
>>> >
>>> > I think there is an issue in how expression translators work when AST
>>> is
>>> > more complex (has more depth). Same code / logic is used across
>>> different
>>> > adapters (Mongo / Geode / ES) so multiple data-sources might be
>>> affected.
>>> >
>>> > Examples
>>> >
>>> > 1. Works
>>> >
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
>>> > "elastic" where _MAP['foo'] in ('1') and true;
>>> >
>>> > 2. Works
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
>>> > "elastic" where _MAP['foo'] ='1' and true;
>>> >
>>> > 3. Works
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
>>> > "elastic" where _MAP['foo'] in ('1', '2');
>>> >
>>> >
>>> > 4. Fails
>>> >
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
>>> > "elastic" where _MAP['foo'] in ('1', '2') and true;
>>> >
>>> >
>>> > 5. Fails
>>> >
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
>>> > "elastic" where true and _MAP['foo'] in ('1', '2');
>>> >
>>> >
>>> > 6. Fails
>>> >
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select count(*) from
>>> > "elastic" where (_MAP['foo'] ='1' or _MAP['foo'] = '2') and true;
>>> >
>>> >
>>> >
>>> > Exception Stack (Elastic Adapter)
>>> >
>>> >
>>> > java.lang.AssertionError: cannot translate OR(=(ITEM($0, 'foo'), '1'),
>>> > =(ITEM($0, 'foo'), '2'))
>>> >
>>> > at org.apache.calcite.adapter.ela
>>> sticsearch.ElasticsearchFilter$
>>> > Translator.translateMatch2(ElasticsearchFilter.java:234)
>>> >
>>> > at org.apache.calcite.adapter.ela
>>> sticsearch.ElasticsearchFilter$
>>> > Translator.translateAnd(ElasticsearchFilter.java:158)
>>> >
>>> > at org.apache.calcite.adapter.ela
>>> sticsearch.ElasticsearchFilter$
>>> > Translator.translateOr(ElasticsearchFilter.java:115)
>>> >
>>> > at org.apache.calcite.adapter.ela
>>> sticsearch.ElasticsearchFilter$
>>> > Translator.translateMatch(ElasticsearchFilter.java:101)
>>> >
>>> > at org.apache.calcite.adapter.ela
>>> sticsearch.ElasticsearchFilter$
>>> > Translator.access$000(ElasticsearchFilter.java:87)
>>> >
>>> > at org.apache.calcite.adapter.elasticsearch.
>>> > ElasticsearchFilter.implement(ElasticsearchFilter.java:80)
>>> >
>>> > at org.apache.calcite.adapter.elasticsearch.
>>> > ElasticsearchRel$Implementor.visitChild(ElasticsearchRel.java:53)
>>> >
>>> > at org.apache.calcite.adapter.elasticsearch.
>>> > ElasticsearchToEnumerableConverter.implement(ElasticsearchTo
>>> EnumerableConve
>>> > rter.java:71)
>>> >
>>> > at org.apache.calcite.adapter.enu
>>> merable.EnumerableRelImplementor.
>>> > visitChild(EnumerableRelImplementor.java:98)
>>> >
>>> > at org.apache.calcite.adapter.enumerable.
>>> > EnumerableAggregate.implement(EnumerableAggregate.java:106)
>>> >
>>> > Exception Stack (Mongo Adapter)
>>> >
>>> > 0: jdbc:calcite:model=target/test-classes/mod> select * from
>>> "mongo"."col"
>>> > where _MAP['foo'] in ('1', '2') and true;
>>> >
>>> > java.lang.AssertionError: cannot translate OR(=(ITEM($0, 'foo'), '1'),
>>> > =(ITEM($0, 'foo'), '2'))
>>> >
>>> > at org.apache.calcite.adapter.mongodb.MongoFilter$
>>> > Translator.translateMatch2(MongoFilter.java:181)
>>> >
>>> > at org.apache.calcite.adapter.mongodb.MongoFilter$
>>> > Translator.translateAnd(MongoFilter.java:116)
>>> >
>>> 

Calcite-Master - Build # 285 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

[DISCUSS] Towards Avatica 1.12.0

[Francis Chuang]

Avatica 1.11.0 was released on March 6 (more than 3 months ago). We 
should discuss the next release (1.12.0).


The current consensus is to have a release in around 2 weeks.

The JIRA tracking the release is CALCITE-2330 [1].

As the release cycle for this would is a bit short, I think it would be 
a good idea to focus our efforts on low hanging fruit, bugs and 
features/enhancements that won't take a lot of time (unless someone is 
able to dedicate significant resources).


Personally, I would love to see the following fixed:

CALCITE-1951 [2]: Avatica with HSQLDB loses fractional seconds. Kevin 
and Josh has done some investigation, so I hope this is a relatively 
simple fix. Test is here: https://github.com/apache/calcite-avatica/pull/36


CALCITE-2250 [3]: Avatica with HSQLDB hangs when using multiple 
transactions. Kevin has done some investigation and the issue is easily 
reproducible.


CALCITE-2219 [4]: Acvtica Connection/Statement/ResultSet don't throw if 
resource is closed. Work has started: 
https://github.com/apache/calcite-avatica/pull/33


CALCITE-2333 [5]: Stop releasing ZIPs. Assigned to myself.

Nice to haves:

CALCITE-1049 [7]: SQLException not correctly propagated. This is 
preventing clients from taking different actions when they encounter 
different SQLExceptions. However, the fix might not be too simple.


I'd also like to use this release to clean up the PRs on Github:

CALCITE-1884 [8]: DateTimeUtils produces incorrect results for days 
before Gregorian cutovers. 
https://github.com/apache/calcite-avatica/pull/11 The PR is almost a 
year old. Can someone please take a look at this so we can merge or 
close it?


CALCITE-2294 [9]: Allow customization for plugging in new authentication 
mechanisms. Is active and will be in this release: 
https://github.com/apache/calcite-avatica/pull/48


CALCITE-2322 [10]: Add fetch size support to connection URL and JDBC 
state. Seems to be implemented, can someone please review? 
https://github.com/apache/calcite-avatica/pull/49


CALCITE-2303 [11]: Support extraction of microseconds, milliseconds, 
epoch, isodow, isoyear and decade. Can someone please review? 
https://github.com/apache/calcite-avatica/pull/50


Are there any other features or bugs people would like implemented or fixed?

Francis

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

[2] https://issues.apache.org/jira/browse/CALCITE-1951

[3] https://issues.apache.org/jira/browse/CALCITE-2250

[4] https://issues.apache.org/jira/browse/CALCITE-2219

[5] https://issues.apache.org/jira/browse/CALCITE-2333

[6] https://issues.apache.org/jira/browse/CALCITE-1049

[7] https://issues.apache.org/jira/browse/CALCITE-1049

[8] https://issues.apache.org/jira/browse/CALCITE-1884

[9] https://issues.apache.org/jira/browse/CALCITE-2294

[10] https://issues.apache.org/jira/browse/CALCITE-2322

[11] https://issues.apache.org/jira/browse/CALCITE-2303

Re: Releases

[Julian Hyde]

Thanks, Francis. Assuming there are no objections, consider yourself
release manager.

We seem to be nearing consensus on release date for Avatica 1.12, but
it would be good to gather a list of "must fix" issues (for which
people are prepared to contribute a fix).

On Mon, May 28, 2018 at 9:50 PM, Francis Chuang
 wrote:
> Hey Julian,
>
> I would like to be the release manager for Avatica 1.12. I think this
> release would be a good opportunity to see if we can resolve some of the
> staler bugs in JIRA.
>
> Sergey: Thanks for offering! Would love to have you help out with this
> release!
>
> Francis
>
> On 29/05/2018 12:52 PM, Julian Hyde wrote:
>>
>> Sergey,
>>
>> Thanks for the offer of help. Since you are not a committer you cannot
>> be release manager* but you can help out. When we find a release
>> manager he/she will let you know what you can do to help.
>>
>> Julian
>>
>> * Strictly, only PMC members can be release manager, but in the last
>> avatica-go release Francis (then a committer) did practically
>> everything except generate and sign the artifacts.
>>
>> On Mon, May 28, 2018 at 6:22 AM, Sergey Nuyanzin 
>> wrote:
>>>
>>> Hello
>>>
>>> If it is possible I would like to be a volunteer here.
>>>
>>> On Sun, May 27, 2018 at 3:06 AM, Julian Hyde  wrote:
>>>
 Thanks, Volodymyr. It would be great if you could be Calcite RM.

 Does anyone volunteer to be release manager for Avatica? It is an easier
 job than Calcite, and as Volodymyr
 says, a great way to gain experience.

 Does anyone have any time constraints for Calcite or Avatica releases?

 We’ve been releasing Calcite every 2-3 months, so if we released Calcite
 on June 19 that would be exactly 3 months. If we need to make an Avatica
 release before that, timing will be tight.

 Julian


> On May 26, 2018, at 2:13 AM, Volodymyr Vysotskyi 

 wrote:
>
> Hello,
>
> I volunteer to be the release manager for Calcite if there are no
> objections. It will be a great experience for me.
>
> Calcite 1.16 was released more than two months ago (March 19), but
> since

 it
>
> depends on the Avatica release, Avatica should be released asap.
>
> I suppose it is needed two weeks for Avatica release, so the estimated
> target date starting Calcite release process is the middle of the Jun.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> сб, 26 трав. 2018 о 08:26 Julian Hyde  пише:
>
>> When should we release Calcite 1.17? When should we release Avatica

 1.12?
>>
>> Anyone volunteer to be release manager?
>>
>> Because of https://issues.apache.org/jira/browse/CALCITE-2303 <
>> https://issues.apache.org/jira/browse/CALCITE-2303>, we need to
>> release
>> Avatica before Calcite.
>>
>> I have logged https://issues.apache.org/jira/browse/CALCITE-2330 <
>> https://issues.apache.org/jira/browse/CALCITE-2330> to track Avatica

 1.12.
>>
>> Julian
>>
>>

>>>
>>> --
>>> Best regards,
>>> Sergey
>
>
>

Calcite-Master - Build # 284 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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