[jira] [Created] (CALCITE-2501) Release Avatica Go 3.1.0

[Francis Chuang (JIRA)]

Francis Chuang created CALCITE-2501:
---

 Summary: Release Avatica Go 3.1.0
 Key: CALCITE-2501
 URL: https://issues.apache.org/jira/browse/CALCITE-2501
 Project: Calcite
  Issue Type: Task
  Components: avatica-go
Affects Versions: avatica-go-3.1.0
Reporter: Francis Chuang
Assignee: Francis Chuang






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

Re: Giving the Calcite logo some love

[Francis Chuang]

The designs I have seen so far look really good! Would it also make 
sense to design a variant for Avatica as well? This is what the current 
Avatica logo looks like: https://calcite.apache.org/avatica/img/logo.png


Francis

On 29/08/2018 7:08 AM, Vladimir Sitnikov wrote:

Stamatis>How about something like the following:

There's left-to-right vs right-to-left issue, however I would claim that
the direction of improvement is right+up.
For instance: BTC price is good when plots go to the right and go upward.

https://svgur.com/s/83y is slanted backward.
That creates perception of "Calcite holding back the progress" or "Apache
pushing C away" or something like that.
Could you flip rhombus so it goes right-up?


Vladimir

[GitHub] calcite-avatica-go pull request #29: [CALCITE-2500] Test against Avatica 1.1...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/29


---

[GitHub] calcite-avatica-go pull request #29: [CALCITE-2500] Test against Avatica 1.1...

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/29

[CALCITE-2500] Test against Avatica 1.12.0 and Phoenix 5.0.0



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go 
bump-avatica-and-phoenix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/29.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #29


commit 49fd3a4c5908ef5151406166de1faadc92ad820f
Author: Francis Chuang 
Date:   2018-08-29T04:01:05Z

[CALCITE-2500] Test against Avatica 1.12.0 and Phoenix 5.0.0




---

[jira] [Created] (CALCITE-2500) Test against Avatica 1.12 and Phoenix 5.0

[Francis Chuang (JIRA)]

Francis Chuang created CALCITE-2500:
---

 Summary: Test against Avatica 1.12 and Phoenix 5.0
 Key: CALCITE-2500
 URL: https://issues.apache.org/jira/browse/CALCITE-2500
 Project: Calcite
  Issue Type: Improvement
  Components: avatica-go
Reporter: Francis Chuang
Assignee: Francis Chuang


Test against Avatica 1.12 and Phoenix 5.0



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

Re: [DISCUSS] Towards Avatica-Go 3.1.0

[Francis Chuang]

I just checked the release script for avatica-go. It looks like md5 and 
zip archives were removed sometime ago, so this should not be a problem.


On 29/08/2018 9:26 AM, Julian Hyde wrote:

True. But you will run into grief from the Apache release police if you do. I 
would strongly recommend following the recommendation. :)



On Aug 28, 2018, at 4:23 PM, Michael Mior  wrote:

Looks like a great plan. Thanks Francis :)

Also, while I think we should drop the .md5 (and I don't see a good reason
not to), SHOULD NOT indicates that it's a recommendation, not a requirement.

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



Le mar. 28 août 2018 à 19:13, Julian Hyde  a écrit :


Thanks for driving this, Francis.

Apache release policy and Calcite release practice have both changed
recently:
* Calcite no longer releases a .zip, only a .tar.gz; and we no longer
release an .md5[1]. If you want to drop the .zip feel free; if not, that’s
fine also.
* Apache policy now says you SHOULD NOT release an .md5[2]; you must drop
that from the release.

Julian

[1]
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.17.0-rc0/




On Aug 28, 2018, at 4:05 PM, Francis Chuang 

wrote:

Hi all,

I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.

Some key things I'd like to address in this release:

- Go 1.11 was released a few days ago and now includes support for

dependency management using "Go modules" (done).

Some history:

The Go community released a package manager called Dep[1] in the middle

of 2017. Dep is designed to be very similar to npm, composer and cargo.
Initially, this was poised to be the official package manager for Go. At
the beginning of 2018, Russ Cox (a member of the Go team) announced vgo
(aka Go modules) which is a different approach to package management for
Go. While there was some push back from the community working on Dep, Go
modules is now officially in the Go tool chain and will be the package
management solution of choice for all Go projects.

Transition plan for Avatica-Go:

Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock

files committed. In terms of the Go team, the current (1.11) and last
(1.10) versions of Go are the actively maintained versions. Since Go 1.10
does not have support for Go modules (but there was a patch release to
support Go modules import paths to work with libraries using Go modules),
we need to keep Dep in place for now. I have added support for Go modules
(go.mod and go.sum files) to support people using Go modules for package
management. When Go 1.12 is released in early 2019, I will remove support
for Dep and all users will be required to use Go modules. This will allow
us to simplify the configuration for continuous integration and the
documentation for using and releasing Avatica-Go.

- Update dependencies (done).

- Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).

- Update documentation (in progress).

This release should be pretty routine and there should be no significant

changes. I will send another email to start a vote in the next few days. If
you have any comments or questions, please let me know.

Francis

[1] https://github.com/golang/dep/releases

Re: joins and low selectivity optimization

[Julian Hyde]

Sure, Calcite makes use of stats in its cost formulas. And you are correct that 
“metadata” is what Calcite calls statistics.

But you have to be careful to only treat statistics as approximate. If the 
statistics were gathered using an “ANALYZE TABLE” command a month ago they may 
be out of date, so you cannot use them to, say, remove “WHERE x < 10” if a 
month ago x only had values 2, 4, and 6.

> On Aug 28, 2018, at 7:14 PM, Andrei Sereda  wrote:
> 
> Thank you, Michael and Julian, for your answers.
> 
> Even if optimizers don't have access to data can they have access to table
> statistics ? If I remember correctly Oracle CBO is estimating selectivity
> based on column distribution (histograms) and some formulas for density
> . I realize these
> statistics are not available for all data stores but can calcite optimizer
> be "smarter" when this data is available ?
> 
> On Tue, Aug 28, 2018 at 9:46 PM Julian Hyde  wrote:
> 
>> If I recall correctly, Hive does this kind of optimization. It’s pretty
>> important you have a date dimension table and your fact table is
>> partitioned on date. Example:
>> 
>>  select *
>>  from sales
>>join date_dim on sales.date_id = date_dim.id
>>  where sales.product_name = ‘foo'
>>  and date_dim.quarter = ‘2018-Q2'
>> 
>> Hive would like to transform it to
>> 
>>  select *
>>  from sales
>>  where date_id in (20180401, 20180402, … , 20180630)
>>  and sales.product_name = ‘foo'
>> 
>> by pre-evaluating the query on the date_dim table. It doesn’t do the
>> optimization at logical planning time (where Calcite is involved) but at
>> physical planning time (which occurs later). The list of date_id values
>> allows it to scan a much more limited set of partitions of the sales fact
>> table.
>> 
>> Michael is correct that optimizers don’t usually have access to data. But
>> if the date_dim table changes only slowly, you could set up a “tripwire”
>> that will invalidate the plan if the date_dim table happens to change
>> between planning and execution.
>> 
>> Julian
>> 
>> 
>> 
>> 
>>> On Aug 28, 2018, at 6:04 PM, Michael Mior  wrote:
>>> 
>>> As far as I am aware, the optimizer has no access to data, only metadata.
>>> The traditional way to solve such problems would be to select among
>>> different join algorithms which perform better for varying cardinalities
>> of
>>> each side of the join. Unfortunately, I think you're likely to have a
>> tough
>>> time extracting the necessary data to do the rewrite you're aiming for.
>>> 
>>> --
>>> Michael Mior
>>> mm...@apache.org
>>> 
>>> 
>>> 
>>> Le mar. 28 août 2018 à 20:34, Andrei Sereda  a écrit :
>>> 
 Hello,
 
 I’m looking for a way to improve performance of a join query.
 
 Suppose one joins two heterogeneous sources t1 and t2 with some
>> predicates.
 
 Further assume that cardinality of one of the predicates is very low
 (compared cardinality of the second one). (How) Is it possible to
>> convert
 second query (predicate) to include results (primary keys) of the first
>> one
 (with low selectivity) ?
 Example
 
 select *from
 t1 left join t1 on (t1.id = t2.id)where
 t1.attr = 'foo' and t2.attr = 'bar'
 
 Let’s say that predicate t1.attr = 'foo' results in 3 rows (id=1, 2, 3).
 Will it be possible to rewrite t2 query to :
 
 select *from t2 where
  id in (1, 2, 3) and t2.attr = 'bar'
 
 I’m aware of existence of Metadata
 <
 
>> https://calcite.apache.org/apidocs/org/apache/calcite/rel/metadata/Metadata.html
> 
 but not sure to use it.
 
 Any hits / directions are appreciated.
 
 Thanks,
 Andrei.
 
>> 
>> 

Re: joins and low selectivity optimization

[Andrei Sereda]

Thank you, Michael and Julian, for your answers.

Even if optimizers don't have access to data can they have access to table
statistics ? If I remember correctly Oracle CBO is estimating selectivity
based on column distribution (histograms) and some formulas for density
. I realize these
statistics are not available for all data stores but can calcite optimizer
be "smarter" when this data is available ?

On Tue, Aug 28, 2018 at 9:46 PM Julian Hyde  wrote:

> If I recall correctly, Hive does this kind of optimization. It’s pretty
> important you have a date dimension table and your fact table is
> partitioned on date. Example:
>
>   select *
>   from sales
> join date_dim on sales.date_id = date_dim.id
>   where sales.product_name = ‘foo'
>   and date_dim.quarter = ‘2018-Q2'
>
> Hive would like to transform it to
>
>   select *
>   from sales
>   where date_id in (20180401, 20180402, … , 20180630)
>   and sales.product_name = ‘foo'
>
> by pre-evaluating the query on the date_dim table. It doesn’t do the
> optimization at logical planning time (where Calcite is involved) but at
> physical planning time (which occurs later). The list of date_id values
> allows it to scan a much more limited set of partitions of the sales fact
> table.
>
> Michael is correct that optimizers don’t usually have access to data. But
> if the date_dim table changes only slowly, you could set up a “tripwire”
> that will invalidate the plan if the date_dim table happens to change
> between planning and execution.
>
> Julian
>
>
>
>
> > On Aug 28, 2018, at 6:04 PM, Michael Mior  wrote:
> >
> > As far as I am aware, the optimizer has no access to data, only metadata.
> > The traditional way to solve such problems would be to select among
> > different join algorithms which perform better for varying cardinalities
> of
> > each side of the join. Unfortunately, I think you're likely to have a
> tough
> > time extracting the necessary data to do the rewrite you're aiming for.
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> >
> >
> > Le mar. 28 août 2018 à 20:34, Andrei Sereda  a écrit :
> >
> >> Hello,
> >>
> >> I’m looking for a way to improve performance of a join query.
> >>
> >> Suppose one joins two heterogeneous sources t1 and t2 with some
> predicates.
> >>
> >> Further assume that cardinality of one of the predicates is very low
> >> (compared cardinality of the second one). (How) Is it possible to
> convert
> >> second query (predicate) to include results (primary keys) of the first
> one
> >> (with low selectivity) ?
> >> Example
> >>
> >> select *from
> >>  t1 left join t1 on (t1.id = t2.id)where
> >>  t1.attr = 'foo' and t2.attr = 'bar'
> >>
> >> Let’s say that predicate t1.attr = 'foo' results in 3 rows (id=1, 2, 3).
> >> Will it be possible to rewrite t2 query to :
> >>
> >> select *from t2 where
> >>   id in (1, 2, 3) and t2.attr = 'bar'
> >>
> >> I’m aware of existence of Metadata
> >> <
> >>
> https://calcite.apache.org/apidocs/org/apache/calcite/rel/metadata/Metadata.html
> >>>
> >> but not sure to use it.
> >>
> >> Any hits / directions are appreciated.
> >>
> >> Thanks,
> >> Andrei.
> >>
>
>

Re: joins and low selectivity optimization

[Julian Hyde]

If I recall correctly, Hive does this kind of optimization. It’s pretty 
important you have a date dimension table and your fact table is partitioned on 
date. Example:

  select *
  from sales
join date_dim on sales.date_id = date_dim.id
  where sales.product_name = ‘foo'
  and date_dim.quarter = ‘2018-Q2'

Hive would like to transform it to

  select *
  from sales
  where date_id in (20180401, 20180402, … , 20180630)
  and sales.product_name = ‘foo'

by pre-evaluating the query on the date_dim table. It doesn’t do the 
optimization at logical planning time (where Calcite is involved) but at 
physical planning time (which occurs later). The list of date_id values allows 
it to scan a much more limited set of partitions of the sales fact table.

Michael is correct that optimizers don’t usually have access to data. But if 
the date_dim table changes only slowly, you could set up a “tripwire” that will 
invalidate the plan if the date_dim table happens to change between planning 
and execution.

Julian




> On Aug 28, 2018, at 6:04 PM, Michael Mior  wrote:
> 
> As far as I am aware, the optimizer has no access to data, only metadata.
> The traditional way to solve such problems would be to select among
> different join algorithms which perform better for varying cardinalities of
> each side of the join. Unfortunately, I think you're likely to have a tough
> time extracting the necessary data to do the rewrite you're aiming for.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le mar. 28 août 2018 à 20:34, Andrei Sereda  a écrit :
> 
>> Hello,
>> 
>> I’m looking for a way to improve performance of a join query.
>> 
>> Suppose one joins two heterogeneous sources t1 and t2 with some predicates.
>> 
>> Further assume that cardinality of one of the predicates is very low
>> (compared cardinality of the second one). (How) Is it possible to convert
>> second query (predicate) to include results (primary keys) of the first one
>> (with low selectivity) ?
>> Example
>> 
>> select *from
>>  t1 left join t1 on (t1.id = t2.id)where
>>  t1.attr = 'foo' and t2.attr = 'bar'
>> 
>> Let’s say that predicate t1.attr = 'foo' results in 3 rows (id=1, 2, 3).
>> Will it be possible to rewrite t2 query to :
>> 
>> select *from t2 where
>>   id in (1, 2, 3) and t2.attr = 'bar'
>> 
>> I’m aware of existence of Metadata
>> <
>> https://calcite.apache.org/apidocs/org/apache/calcite/rel/metadata/Metadata.html
>>> 
>> but not sure to use it.
>> 
>> Any hits / directions are appreciated.
>> 
>> Thanks,
>> Andrei.
>> 

Re: joins and low selectivity optimization

[Michael Mior]

As far as I am aware, the optimizer has no access to data, only metadata.
The traditional way to solve such problems would be to select among
different join algorithms which perform better for varying cardinalities of
each side of the join. Unfortunately, I think you're likely to have a tough
time extracting the necessary data to do the rewrite you're aiming for.

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



Le mar. 28 août 2018 à 20:34, Andrei Sereda  a écrit :

> Hello,
>
> I’m looking for a way to improve performance of a join query.
>
> Suppose one joins two heterogeneous sources t1 and t2 with some predicates.
>
> Further assume that cardinality of one of the predicates is very low
> (compared cardinality of the second one). (How) Is it possible to convert
> second query (predicate) to include results (primary keys) of the first one
> (with low selectivity) ?
> Example
>
> select *from
>   t1 left join t1 on (t1.id = t2.id)where
>   t1.attr = 'foo' and t2.attr = 'bar'
>
> Let’s say that predicate t1.attr = 'foo' results in 3 rows (id=1, 2, 3).
> Will it be possible to rewrite t2 query to :
>
> select *from t2 where
>id in (1, 2, 3) and t2.attr = 'bar'
>
> I’m aware of existence of Metadata
> <
> https://calcite.apache.org/apidocs/org/apache/calcite/rel/metadata/Metadata.html
> >
> but not sure to use it.
>
> Any hits / directions are appreciated.
>
> Thanks,
> Andrei.
>

joins and low selectivity optimization

[Andrei Sereda]

Hello,

I’m looking for a way to improve performance of a join query.

Suppose one joins two heterogeneous sources t1 and t2 with some predicates.

Further assume that cardinality of one of the predicates is very low
(compared cardinality of the second one). (How) Is it possible to convert
second query (predicate) to include results (primary keys) of the first one
(with low selectivity) ?
Example

select *from
  t1 left join t1 on (t1.id = t2.id)where
  t1.attr = 'foo' and t2.attr = 'bar'

Let’s say that predicate t1.attr = 'foo' results in 3 rows (id=1, 2, 3).
Will it be possible to rewrite t2 query to :

select *from t2 where
   id in (1, 2, 3) and t2.attr = 'bar'

I’m aware of existence of Metadata

but not sure to use it.

Any hits / directions are appreciated.

Thanks,
Andrei.

Re: Calcite contributions

[Julian Hyde]

Again, I’m going to speak more strongly than Michael.

Vladimir,

Even if you are right, that doesn’t give you the right to be uncivil. 
Over-riding Zoltan’s PR, for which he had asked for a review, but not received, 
was not OK.

If you had just said “Hey Zoltan, I think I’ve come up with a better fix than 
your PR; do you mind if I commit it?” then Zoltan would have said “Sure”. 
Please do that next time.

If we don’t have civility and trust, this community will fall apart. 
Maintaining civility is more important than fixing a bug.

Julian


> On Aug 28, 2018, at 4:32 PM, Michael Mior  wrote:
> 
> Thanks for clarifying. It seems like this is a case where there's a broader
> discussion to be had about the merits of the optimization (completely
> separate from the issue at hand).
> 
> 1) I'm not opposed to developing a fix that's better than one which was
> already proposed although I think it would be good to run it by whoever
> originally filed the issue.
> 2) I think "backward" here is subjective. I'm not picking a side here, but
> certainly there are cases where disabling a buggy optimization is the right
> thing to do.
> 3) Developing a different fix may sometimes be the right thing to do, but I
> think other contributors would appreciate a discussion before their code is
> effectively ignored.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le mar. 28 août 2018 à 17:01, Vladimir Sitnikov 
> a écrit :
> 
>> Michael>One of the other side effects in this case
>> Michael>seems to be (without having examined the technical merit of either
>> Michael>solution) that the fix which was ultimately committed still didn't
>> solve
>> Michael>the original issue.
>> 
>> I'm afraid you did are wrong here.
>> My first commit implemented exactly one test. I removed @Ignored from the
>> test and implemented a fix.
>> 
>> It turned out Zoltan crafted more complex test that identified a bug in the
>> v1 of the implementation.
>> Note: that was a new test, and it was not included in PR707.
>> Note: there are millions of test cases missing, and I know the proper way
>> to cover it.
>> However, it looks like everybody here likes "one test per issue" approach
>> more, so I follow it somehow: I unlock a single test, so everybody is
>> happy.
>> 
>> Michael>In this case, it seems like Zoltan was still willing to help
>> provide a
>> solution
>> 
>> AFAIK, no-one (including Zoltan) cares to suggest a test case to defeat
>> current code in master.
>> I treat that as "the feature is good enough".
>> 
>> Michael>see the last activity on both of those before the period of
>> inactivity was
>> by Zoltan
>> 
>> My point here is
>> 1) It takes ~30 min to "develop+test" the fix
>> 2) PR707 goes in opposite direction: it disables the optimization instead
>> of just unlocking a single @Ignore test
>> 3) The bug does bother me
>> ==> I just fix it and merge it.
>> On top of that, I see nothing I could reuse from PR707, so I had to just
>> discard it.
>> 
>> Vladimir
>> 

Re: Calcite contributions

[Michael Mior]

Thanks for clarifying. It seems like this is a case where there's a broader
discussion to be had about the merits of the optimization (completely
separate from the issue at hand).

1) I'm not opposed to developing a fix that's better than one which was
already proposed although I think it would be good to run it by whoever
originally filed the issue.
2) I think "backward" here is subjective. I'm not picking a side here, but
certainly there are cases where disabling a buggy optimization is the right
thing to do.
3) Developing a different fix may sometimes be the right thing to do, but I
think other contributors would appreciate a discussion before their code is
effectively ignored.

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



Le mar. 28 août 2018 à 17:01, Vladimir Sitnikov 
a écrit :

> Michael>One of the other side effects in this case
> Michael>seems to be (without having examined the technical merit of either
> Michael>solution) that the fix which was ultimately committed still didn't
> solve
> Michael>the original issue.
>
> I'm afraid you did are wrong here.
> My first commit implemented exactly one test. I removed @Ignored from the
> test and implemented a fix.
>
> It turned out Zoltan crafted more complex test that identified a bug in the
> v1 of the implementation.
> Note: that was a new test, and it was not included in PR707.
> Note: there are millions of test cases missing, and I know the proper way
> to cover it.
> However, it looks like everybody here likes "one test per issue" approach
> more, so I follow it somehow: I unlock a single test, so everybody is
> happy.
>
> Michael>In this case, it seems like Zoltan was still willing to help
> provide a
> solution
>
> AFAIK, no-one (including Zoltan) cares to suggest a test case to defeat
> current code in master.
> I treat that as "the feature is good enough".
>
> Michael>see the last activity on both of those before the period of
> inactivity was
> by Zoltan
>
> My point here is
> 1) It takes ~30 min to "develop+test" the fix
> 2) PR707 goes in opposite direction: it disables the optimization instead
> of just unlocking a single @Ignore test
> 3) The bug does bother me
> ==> I just fix it and merge it.
> On top of that, I see nothing I could reuse from PR707, so I had to just
> discard it.
>
> Vladimir
>

[jira] [Created] (CALCITE-2499) Drop support for dep

[Francis Chuang (JIRA)]

Francis Chuang created CALCITE-2499:
---

 Summary: Drop support for dep
 Key: CALCITE-2499
 URL: https://issues.apache.org/jira/browse/CALCITE-2499
 Project: Calcite
  Issue Type: Task
  Components: avatica-go
Affects Versions: avatica-go-4.0.0
Reporter: Francis Chuang
Assignee: Francis Chuang


We should drop support for dep when Go 1.12 is released (Jan 2019). Go modules 
is now the official package management solution (since Go 1.11).



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

Re: [DISCUSS] Towards Avatica-Go 3.1.0

[Francis Chuang]

I will also be including the transition plan in the release notes and 
the news item for the release. The JIRA case is CALCITE-2335.


I believe zip archives were removed, but I will check to confirm.
I will also check to confirm if we are still releasing a .md5 for 
Avatica-Go. MD5 is easily crackable with modern computing power, so I 
will remove it if we are still releasing it.


Francis

[1]https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-2335

On 29/08/2018 9:18 AM, Julian Hyde wrote:

Also, it’s helpful that you are publishing the transition plan up-front. Do you 
plan to include it in the release notes, or perhaps reference a JIRA case? 
Users of avatica-go may not be subscribed to this list, but they still need to 
be aware of the transition plan.


On Aug 28, 2018, at 4:05 PM, Francis Chuang  wrote:

Hi all,

I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.

Some key things I'd like to address in this release:

- Go 1.11 was released a few days ago and now includes support for dependency management 
using "Go modules" (done).

Some history:

The Go community released a package manager called Dep[1] in the middle of 
2017. Dep is designed to be very similar to npm, composer and cargo. Initially, 
this was poised to be the official package manager for Go. At the beginning of 
2018, Russ Cox (a member of the Go team) announced vgo (aka Go modules) which 
is a different approach to package management for Go. While there was some push 
back from the community working on Dep, Go modules is now officially in the Go 
tool chain and will be the package management solution of choice for all Go 
projects.

Transition plan for Avatica-Go:

Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock files 
committed. In terms of the Go team, the current (1.11) and last (1.10) versions 
of Go are the actively maintained versions. Since Go 1.10 does not have support 
for Go modules (but there was a patch release to support Go modules import 
paths to work with libraries using Go modules), we need to keep Dep in place 
for now. I have added support for Go modules (go.mod and go.sum files) to 
support people using Go modules for package management. When Go 1.12 is 
released in early 2019, I will remove support for Dep and all users will be 
required to use Go modules. This will allow us to simplify the configuration 
for continuous integration and the documentation for using and releasing 
Avatica-Go.

- Update dependencies (done).

- Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).

- Update documentation (in progress).

This release should be pretty routine and there should be no significant 
changes. I will send another email to start a vote in the next few days. If you 
have any comments or questions, please let me know.

Francis

[1] https://github.com/golang/dep/releases

Re: [DISCUSS] Towards Avatica-Go 3.1.0

[Julian Hyde]

True. But you will run into grief from the Apache release police if you do. I 
would strongly recommend following the recommendation. :)


> On Aug 28, 2018, at 4:23 PM, Michael Mior  wrote:
> 
> Looks like a great plan. Thanks Francis :)
> 
> Also, while I think we should drop the .md5 (and I don't see a good reason
> not to), SHOULD NOT indicates that it's a recommendation, not a requirement.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le mar. 28 août 2018 à 19:13, Julian Hyde  a écrit :
> 
>> Thanks for driving this, Francis.
>> 
>> Apache release policy and Calcite release practice have both changed
>> recently:
>> * Calcite no longer releases a .zip, only a .tar.gz; and we no longer
>> release an .md5[1]. If you want to drop the .zip feel free; if not, that’s
>> fine also.
>> * Apache policy now says you SHOULD NOT release an .md5[2]; you must drop
>> that from the release.
>> 
>> Julian
>> 
>> [1]
>> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.17.0-rc0/
>> >> 
>> 
>> [2] https://www.apache.org/dev/release-distribution.html#sigs-and-sums <
>> https://www.apache.org/dev/release-distribution.html#sigs-and-sums>
>> 
>> 
>>> On Aug 28, 2018, at 4:05 PM, Francis Chuang 
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.
>>> 
>>> Some key things I'd like to address in this release:
>>> 
>>> - Go 1.11 was released a few days ago and now includes support for
>> dependency management using "Go modules" (done).
>>> 
>>> Some history:
>>> 
>>> The Go community released a package manager called Dep[1] in the middle
>> of 2017. Dep is designed to be very similar to npm, composer and cargo.
>> Initially, this was poised to be the official package manager for Go. At
>> the beginning of 2018, Russ Cox (a member of the Go team) announced vgo
>> (aka Go modules) which is a different approach to package management for
>> Go. While there was some push back from the community working on Dep, Go
>> modules is now officially in the Go tool chain and will be the package
>> management solution of choice for all Go projects.
>>> 
>>> Transition plan for Avatica-Go:
>>> 
>>> Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock
>> files committed. In terms of the Go team, the current (1.11) and last
>> (1.10) versions of Go are the actively maintained versions. Since Go 1.10
>> does not have support for Go modules (but there was a patch release to
>> support Go modules import paths to work with libraries using Go modules),
>> we need to keep Dep in place for now. I have added support for Go modules
>> (go.mod and go.sum files) to support people using Go modules for package
>> management. When Go 1.12 is released in early 2019, I will remove support
>> for Dep and all users will be required to use Go modules. This will allow
>> us to simplify the configuration for continuous integration and the
>> documentation for using and releasing Avatica-Go.
>>> 
>>> - Update dependencies (done).
>>> 
>>> - Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).
>>> 
>>> - Update documentation (in progress).
>>> 
>>> This release should be pretty routine and there should be no significant
>> changes. I will send another email to start a vote in the next few days. If
>> you have any comments or questions, please let me know.
>>> 
>>> Francis
>>> 
>>> [1] https://github.com/golang/dep/releases
>>> 
>> 
>> 

Re: [DISCUSS] Towards Avatica-Go 3.1.0

[Michael Mior]

Looks like a great plan. Thanks Francis :)

Also, while I think we should drop the .md5 (and I don't see a good reason
not to), SHOULD NOT indicates that it's a recommendation, not a requirement.

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



Le mar. 28 août 2018 à 19:13, Julian Hyde  a écrit :

> Thanks for driving this, Francis.
>
> Apache release policy and Calcite release practice have both changed
> recently:
> * Calcite no longer releases a .zip, only a .tar.gz; and we no longer
> release an .md5[1]. If you want to drop the .zip feel free; if not, that’s
> fine also.
> * Apache policy now says you SHOULD NOT release an .md5[2]; you must drop
> that from the release.
>
> Julian
>
> [1]
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.17.0-rc0/
>  >
>
> [2] https://www.apache.org/dev/release-distribution.html#sigs-and-sums <
> https://www.apache.org/dev/release-distribution.html#sigs-and-sums>
>
>
> > On Aug 28, 2018, at 4:05 PM, Francis Chuang 
> wrote:
> >
> > Hi all,
> >
> > I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.
> >
> > Some key things I'd like to address in this release:
> >
> > - Go 1.11 was released a few days ago and now includes support for
> dependency management using "Go modules" (done).
> >
> > Some history:
> >
> > The Go community released a package manager called Dep[1] in the middle
> of 2017. Dep is designed to be very similar to npm, composer and cargo.
> Initially, this was poised to be the official package manager for Go. At
> the beginning of 2018, Russ Cox (a member of the Go team) announced vgo
> (aka Go modules) which is a different approach to package management for
> Go. While there was some push back from the community working on Dep, Go
> modules is now officially in the Go tool chain and will be the package
> management solution of choice for all Go projects.
> >
> > Transition plan for Avatica-Go:
> >
> > Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock
> files committed. In terms of the Go team, the current (1.11) and last
> (1.10) versions of Go are the actively maintained versions. Since Go 1.10
> does not have support for Go modules (but there was a patch release to
> support Go modules import paths to work with libraries using Go modules),
> we need to keep Dep in place for now. I have added support for Go modules
> (go.mod and go.sum files) to support people using Go modules for package
> management. When Go 1.12 is released in early 2019, I will remove support
> for Dep and all users will be required to use Go modules. This will allow
> us to simplify the configuration for continuous integration and the
> documentation for using and releasing Avatica-Go.
> >
> > - Update dependencies (done).
> >
> > - Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).
> >
> > - Update documentation (in progress).
> >
> > This release should be pretty routine and there should be no significant
> changes. I will send another email to start a vote in the next few days. If
> you have any comments or questions, please let me know.
> >
> > Francis
> >
> > [1] https://github.com/golang/dep/releases
> >
>
>

Re: [DISCUSS] Towards Avatica-Go 3.1.0

[Julian Hyde]

Also, it’s helpful that you are publishing the transition plan up-front. Do you 
plan to include it in the release notes, or perhaps reference a JIRA case? 
Users of avatica-go may not be subscribed to this list, but they still need to 
be aware of the transition plan.

> On Aug 28, 2018, at 4:05 PM, Francis Chuang  wrote:
> 
> Hi all,
> 
> I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.
> 
> Some key things I'd like to address in this release:
> 
> - Go 1.11 was released a few days ago and now includes support for dependency 
> management using "Go modules" (done).
> 
> Some history:
> 
> The Go community released a package manager called Dep[1] in the middle of 
> 2017. Dep is designed to be very similar to npm, composer and cargo. 
> Initially, this was poised to be the official package manager for Go. At the 
> beginning of 2018, Russ Cox (a member of the Go team) announced vgo (aka Go 
> modules) which is a different approach to package management for Go. While 
> there was some push back from the community working on Dep, Go modules is now 
> officially in the Go tool chain and will be the package management solution 
> of choice for all Go projects.
> 
> Transition plan for Avatica-Go:
> 
> Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock files 
> committed. In terms of the Go team, the current (1.11) and last (1.10) 
> versions of Go are the actively maintained versions. Since Go 1.10 does not 
> have support for Go modules (but there was a patch release to support Go 
> modules import paths to work with libraries using Go modules), we need to 
> keep Dep in place for now. I have added support for Go modules (go.mod and 
> go.sum files) to support people using Go modules for package management. When 
> Go 1.12 is released in early 2019, I will remove support for Dep and all 
> users will be required to use Go modules. This will allow us to simplify the 
> configuration for continuous integration and the documentation for using and 
> releasing Avatica-Go.
> 
> - Update dependencies (done).
> 
> - Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).
> 
> - Update documentation (in progress).
> 
> This release should be pretty routine and there should be no significant 
> changes. I will send another email to start a vote in the next few days. If 
> you have any comments or questions, please let me know.
> 
> Francis
> 
> [1] https://github.com/golang/dep/releases
> 

Re: [DISCUSS] Towards Avatica-Go 3.1.0

[Julian Hyde]

Thanks for driving this, Francis.

Apache release policy and Calcite release practice have both changed recently:
* Calcite no longer releases a .zip, only a .tar.gz; and we no longer release 
an .md5[1]. If you want to drop the .zip feel free; if not, that’s fine also.
* Apache policy now says you SHOULD NOT release an .md5[2]; you must drop that 
from the release.

Julian

[1] https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.17.0-rc0/ 


[2] https://www.apache.org/dev/release-distribution.html#sigs-and-sums 



> On Aug 28, 2018, at 4:05 PM, Francis Chuang  wrote:
> 
> Hi all,
> 
> I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.
> 
> Some key things I'd like to address in this release:
> 
> - Go 1.11 was released a few days ago and now includes support for dependency 
> management using "Go modules" (done).
> 
> Some history:
> 
> The Go community released a package manager called Dep[1] in the middle of 
> 2017. Dep is designed to be very similar to npm, composer and cargo. 
> Initially, this was poised to be the official package manager for Go. At the 
> beginning of 2018, Russ Cox (a member of the Go team) announced vgo (aka Go 
> modules) which is a different approach to package management for Go. While 
> there was some push back from the community working on Dep, Go modules is now 
> officially in the Go tool chain and will be the package management solution 
> of choice for all Go projects.
> 
> Transition plan for Avatica-Go:
> 
> Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock files 
> committed. In terms of the Go team, the current (1.11) and last (1.10) 
> versions of Go are the actively maintained versions. Since Go 1.10 does not 
> have support for Go modules (but there was a patch release to support Go 
> modules import paths to work with libraries using Go modules), we need to 
> keep Dep in place for now. I have added support for Go modules (go.mod and 
> go.sum files) to support people using Go modules for package management. When 
> Go 1.12 is released in early 2019, I will remove support for Dep and all 
> users will be required to use Go modules. This will allow us to simplify the 
> configuration for continuous integration and the documentation for using and 
> releasing Avatica-Go.
> 
> - Update dependencies (done).
> 
> - Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).
> 
> - Update documentation (in progress).
> 
> This release should be pretty routine and there should be no significant 
> changes. I will send another email to start a vote in the next few days. If 
> you have any comments or questions, please let me know.
> 
> Francis
> 
> [1] https://github.com/golang/dep/releases
> 

[GitHub] calcite-avatica-go pull request #28: [CALCITE-2335] Set module version to v3

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/28


---

[GitHub] calcite-avatica-go pull request #28: [CALCITE-2335] Set module version to v3

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/28

[CALCITE-2335] Set module version to v3



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go 
fix-go-module-version

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/28.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #28


commit eb4d11c77d462c59c4376381972b4b86aba5037a
Author: Francis Chuang 
Date:   2018-08-28T23:06:16Z

[CALCITE-2335] Set module version to v3




---

[DISCUSS] Towards Avatica-Go 3.1.0

[Francis Chuang]

Hi all,

I'd like to start a vote for Avatica-Go 3.1.0 over the next few days.

Some key things I'd like to address in this release:

- Go 1.11 was released a few days ago and now includes support for 
dependency management using "Go modules" (done).


Some history:

The Go community released a package manager called Dep[1] in the middle 
of 2017. Dep is designed to be very similar to npm, composer and cargo. 
Initially, this was poised to be the official package manager for Go. At 
the beginning of 2018, Russ Cox (a member of the Go team) announced vgo 
(aka Go modules) which is a different approach to package management for 
Go. While there was some push back from the community working on Dep, Go 
modules is now officially in the Go tool chain and will be the package 
management solution of choice for all Go projects.


Transition plan for Avatica-Go:

Avatica-Go currently uses Dep and has the Gopkg.toml and Gopkg.lock 
files committed. In terms of the Go team, the current (1.11) and last 
(1.10) versions of Go are the actively maintained versions. Since Go 
1.10 does not have support for Go modules (but there was a patch release 
to support Go modules import paths to work with libraries using Go 
modules), we need to keep Dep in place for now. I have added support for 
Go modules (go.mod and go.sum files) to support people using Go modules 
for package management. When Go 1.12 is released in early 2019, I will 
remove support for Dep and all users will be required to use Go modules. 
This will allow us to simplify the configuration for continuous 
integration and the documentation for using and releasing Avatica-Go.


- Update dependencies (done).

- Test against Avatica 1.12 and Phoenix 5.0.0 (in progress).

- Update documentation (in progress).

This release should be pretty routine and there should be no significant 
changes. I will send another email to start a vote in the next few days. 
If you have any comments or questions, please let me know.


Francis

[1] https://github.com/golang/dep/releases

[jira] [Created] (CALCITE-2498) geode adapter quotes booleans as strings ('true' / 'false')

[Andrei Sereda (JIRA)]

Andrei Sereda created CALCITE-2498:
--

 Summary: geode adapter quotes booleans as strings ('true' / 
'false')
 Key: CALCITE-2498
 URL: https://issues.apache.org/jira/browse/CALCITE-2498
 Project: Calcite
  Issue Type: Bug
  Components: geode
Reporter: Andrei Sereda
Assignee: Julian Hyde


Having simple query:

{code:sql}
// SQL (calcite)
select * from geode where isActive = true
// OQL (geode)
select * from /region where isActive = 'true'
{code}



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

Re: Giving the Calcite logo some love

[Vladimir Sitnikov]

Stamatis>How about something like the following:

There's left-to-right vs right-to-left issue, however I would claim that
the direction of improvement is right+up.
For instance: BTC price is good when plots go to the right and go upward.

https://svgur.com/s/83y is slanted backward.
That creates perception of "Calcite holding back the progress" or "Apache
pushing C away" or something like that.
Could you flip rhombus so it goes right-up?


Vladimir

Re: Calcite contributions

[Vladimir Sitnikov]

Michael>One of the other side effects in this case
Michael>seems to be (without having examined the technical merit of either
Michael>solution) that the fix which was ultimately committed still didn't
solve
Michael>the original issue.

I'm afraid you did are wrong here.
My first commit implemented exactly one test. I removed @Ignored from the
test and implemented a fix.

It turned out Zoltan crafted more complex test that identified a bug in the
v1 of the implementation.
Note: that was a new test, and it was not included in PR707.
Note: there are millions of test cases missing, and I know the proper way
to cover it.
However, it looks like everybody here likes "one test per issue" approach
more, so I follow it somehow: I unlock a single test, so everybody is happy.

Michael>In this case, it seems like Zoltan was still willing to help
provide a
solution

AFAIK, no-one (including Zoltan) cares to suggest a test case to defeat
current code in master.
I treat that as "the feature is good enough".

Michael>see the last activity on both of those before the period of
inactivity was
by Zoltan

My point here is
1) It takes ~30 min to "develop+test" the fix
2) PR707 goes in opposite direction: it disables the optimization instead
of just unlocking a single @Ignore test
3) The bug does bother me
==> I just fix it and merge it.
On top of that, I see nothing I could reuse from PR707, so I had to just
discard it.

Vladimir

Re: Giving the Calcite logo some love

[Stamatis Zampetakis]

How about something like the following:

https://svgur.com/s/83y

Minimal presence of drop-shadow just to keep a bit the birefringence effect
and text next to the shape.



Στις Τρί, 28 Αυγ 2018 στις 9:54 μ.μ., ο/η Julian Hyde 
έγραψε:

> The drop shadow is kind of the point (see birefringence[1]).
>
> But I agree that it makes the logo difficult to read.
>
> Julian
>
> [1] https://en.wikipedia.org/wiki/Birefringence <
> https://en.wikipedia.org/wiki/Birefringence>
>
> > On Aug 28, 2018, at 11:44 AM, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> >
> > Stamatis>From the discussion so far, I came also with a few quick drafts
> >
> > How about making text separate from the shape?
> > E.g. shape on the left, text on the right.
> >
> > Michael>without the drop shadow on the text
> >
> > +1
> >
> > Vladimir
>
>

Re: Calcite contributions

[Michael Mior]

My thought was that the least that should be done is post a note that the
issue has been fixed. However (others can correct me if I'm wrong), it
seems that you did do this before Zoltan sent out his earlier email. In any
case, while it's true that both of the issue and the PR were "inactive", I
see the last activity on both of those before the period of inactivity was
by Zoltan. I don't see this as a case of the issue being abandoned. When
there's no response from a contributor, developing and committing an
alternate fix seems reasonable.

In this case, it seems like Zoltan was still willing to help provide a
solution so I don't think it's appropriate to ignore the work he put in
which seems to be what happened. One of the other side effects in this case
seems to be (without having examined the technical merit of either
solution) that the fix which was ultimately committed still didn't solve
the original issue.

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



Le mar. 28 août 2018 à 15:09, Vladimir Sitnikov 
a écrit :

> Michael>I still think
> Michael>this should be communicated to the original contributor along with
> a link
> Michael>to the fix. This at least gives the person an opportunity to learn.
>
> I have linked the original PR and the fix, and it did help Zoltan to note
> an alternative implementation.
>
> Julian>Your behavior was extremely rude.
>
> Do you mean just CALCITE-2327?
> Do you mean other cases?
>
> Julian>It does seem that you were technically correct in this case. But we
> require civility in this community.
>
> Does that imply the behavior was not civil?
>
> The bug is trivial, and I really see no reasons to spend time on discussing
> the bits.
>
> Remember: CALCITE-2327/PR707 was inactive since July. The fix takes just
> 10-20minutes.
> What sense does it make to ping the issue?
> I would rather commit the fix than spend days on discussion. No-one would
> learn from that discussion.
>
> As you remember, bike-shedding causes
> https://issues.apache.org/jira/browse/CALCITE-2438
>
> Vladimir
>

Calcite-Master - Build # 801 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Re: Calcite contributions

[Vladimir Sitnikov]

Michael>I still think
Michael>this should be communicated to the original contributor along with
a link
Michael>to the fix. This at least gives the person an opportunity to learn.

I have linked the original PR and the fix, and it did help Zoltan to note
an alternative implementation.

Julian>Your behavior was extremely rude.

Do you mean just CALCITE-2327?
Do you mean other cases?

Julian>It does seem that you were technically correct in this case. But we
require civility in this community.

Does that imply the behavior was not civil?

The bug is trivial, and I really see no reasons to spend time on discussing
the bits.

Remember: CALCITE-2327/PR707 was inactive since July. The fix takes just
10-20minutes.
What sense does it make to ping the issue?
I would rather commit the fix than spend days on discussion. No-one would
learn from that discussion.

As you remember, bike-shedding causes
https://issues.apache.org/jira/browse/CALCITE-2438

Vladimir

Re: Giving the Calcite logo some love

[Julian Hyde]

The drop shadow is kind of the point (see birefringence[1]).

But I agree that it makes the logo difficult to read.

Julian

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


> On Aug 28, 2018, at 11:44 AM, Vladimir Sitnikov  
> wrote:
> 
> Stamatis>From the discussion so far, I came also with a few quick drafts
> 
> How about making text separate from the shape?
> E.g. shape on the left, text on the right.
> 
> Michael>without the drop shadow on the text
> 
> +1
> 
> Vladimir

[jira] [Created] (CALCITE-2497) Update Janino version to 3.0.9

[Volodymyr Vysotskyi (JIRA)]

Volodymyr Vysotskyi created CALCITE-2497:


 Summary: Update Janino version to 3.0.9
 Key: CALCITE-2497
 URL: https://issues.apache.org/jira/browse/CALCITE-2497
 Project: Calcite
  Issue Type: Task
Affects Versions: 1.17.0
Reporter: Volodymyr Vysotskyi
Assignee: Volodymyr Vysotskyi
 Fix For: 1.18.0


Update Janino version to 3.0.9 where was fixed 
[https://github.com/janino-compiler/janino/issues/47], and remove workaround 
made in CALCITE-2261 because of this issue.



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

Re: Giving the Calcite logo some love

[Vladimir Sitnikov]

Stamatis>From the discussion so far, I came also with a few quick drafts

How about making text separate from the shape?
E.g. shape on the left, text on the right.

Michael>without the drop shadow on the text

+1

Vladimir

Re: Giving the Calcite logo some love

[Michael Mior]

Personally, I would prefer those without the drop shadow on the text, but I
like them as well :)
--
Michael Mior
mm...@apache.org



Le mar. 28 août 2018 à 14:40, Stamatis Zampetakis  a
écrit :

> I like all the logos that Daniel proposed, but I slightly prefer the second
> batch.
>
> From the discussion so far, I came also with a few quick drafts:
>
> https://svgur.com/s/85N
> https://svgur.com/s/864
> https://svgshare.com/i/84s.svg
>
> I can further improve them if there is any interest.
>
> Best,
> Stamatis
>
> Στις Τρί, 28 Αυγ 2018 στις 1:58 π.μ., ο/η Michael Mior 
> έγραψε:
>
> > I personally quite like the second one of these although I believe I
> prefer
> > the text from the previous logo. That said, of everything I've seen
> Daniel
> > sent so far, I think any of them would be a big improvement that I'd be
> > happy with :)
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> >
> >
> > Le lun. 27 août 2018 à 16:00, Daniel Gruno  a
> écrit
> > :
> >
> > > On 08/27/2018 09:04 PM, Julian Hyde wrote:
> > > > Everyone, please be sure to cc Daniel when you reply to this thread.
> > (He
> > > is making the same offer to a lot of projects and understandably he
> does
> > > not want to subscribe to all of their dev lists.)
> > >
> > > Indeed :D
> > >
> > > I had another idea thrown at me, with refraction and primary colors as
> > > an idea, and this is the output:
> > >
> >
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposal2.svg
> > > (it's got a few versions to look at). Perhaps that is more to the
> spirit
> > > of the project?
> > >
> > > With regards,
> > > Daniel.
> > >
> > > >
> > > >> On Aug 27, 2018, at 5:37 AM, Michael Mior  wrote:
> > > >>
> > > >> Definitely agreed that the logo could use some love. I like what
> > you've
> > > >> done with the type in the logo and I also like Julian's suggestion
> of
> > > >> refraction. I'll see what I can do over the next couple days about
> > > >> combining those two things.
> > > >>
> > > >> --
> > > >> Michael Mior
> > > >> mm...@apache.org
> > > >>
> > > >>
> > > >>
> > > >> Le dim. 26 août 2018 à 16:56, Daniel Gruno  a
> > > écrit :
> > > >>
> > > >>> Hello, awesome Calcite people!
> > > >>>
> > > >>> As some of you may know, I'm on an arduous mission of gathering and
> > > >>> touching up all logos we have at Apache. During this task, I
> realized
> > > >>> the calcite logo has some flaws that does not make it super fit for
> > > >>> print, so perhaps it's time to look for a new logo?
> > > >>>
> > > >>> I did a quick proposal, figuring "calcite...minerals...mining!" -
> if
> > > I'm
> > > >>> completely off track, let me know :D Anyway, the proposal is at:
> > > >>>
> > > >>>
> > >
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg
> > > >>>
> > > >>> (current logo is found at
> > > >>> http://www.apache.org/logos/comdev-test/#calcite for reference)
> > > >>>
> > > >>> If you like it, it's hereby ALv2 so feel free to use it.
> > > >>> If you want changes, or maybe a logo contest, that's also a-okay!
> > Just
> > > >>> let me know if you have feedback, and remember to CC me if so, as
> I'm
> > > >>> not on this mailing list.
> > > >>>
> > > >>> With warm regards,
> > > >>> Daniel.
> > > >>>
> > > >
> > >
> > >
> >
>

Re: Giving the Calcite logo some love

[Stamatis Zampetakis]

I like all the logos that Daniel proposed, but I slightly prefer the second
batch.

>From the discussion so far, I came also with a few quick drafts:

https://svgur.com/s/85N
https://svgur.com/s/864
https://svgshare.com/i/84s.svg

I can further improve them if there is any interest.

Best,
Stamatis

Στις Τρί, 28 Αυγ 2018 στις 1:58 π.μ., ο/η Michael Mior 
έγραψε:

> I personally quite like the second one of these although I believe I prefer
> the text from the previous logo. That said, of everything I've seen Daniel
> sent so far, I think any of them would be a big improvement that I'd be
> happy with :)
>
> --
> Michael Mior
> mm...@apache.org
>
>
>
> Le lun. 27 août 2018 à 16:00, Daniel Gruno  a écrit
> :
>
> > On 08/27/2018 09:04 PM, Julian Hyde wrote:
> > > Everyone, please be sure to cc Daniel when you reply to this thread.
> (He
> > is making the same offer to a lot of projects and understandably he does
> > not want to subscribe to all of their dev lists.)
> >
> > Indeed :D
> >
> > I had another idea thrown at me, with refraction and primary colors as
> > an idea, and this is the output:
> >
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposal2.svg
> > (it's got a few versions to look at). Perhaps that is more to the spirit
> > of the project?
> >
> > With regards,
> > Daniel.
> >
> > >
> > >> On Aug 27, 2018, at 5:37 AM, Michael Mior  wrote:
> > >>
> > >> Definitely agreed that the logo could use some love. I like what
> you've
> > >> done with the type in the logo and I also like Julian's suggestion of
> > >> refraction. I'll see what I can do over the next couple days about
> > >> combining those two things.
> > >>
> > >> --
> > >> Michael Mior
> > >> mm...@apache.org
> > >>
> > >>
> > >>
> > >> Le dim. 26 août 2018 à 16:56, Daniel Gruno  a
> > écrit :
> > >>
> > >>> Hello, awesome Calcite people!
> > >>>
> > >>> As some of you may know, I'm on an arduous mission of gathering and
> > >>> touching up all logos we have at Apache. During this task, I realized
> > >>> the calcite logo has some flaws that does not make it super fit for
> > >>> print, so perhaps it's time to look for a new logo?
> > >>>
> > >>> I did a quick proposal, figuring "calcite...minerals...mining!" - if
> > I'm
> > >>> completely off track, let me know :D Anyway, the proposal is at:
> > >>>
> > >>>
> > http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg
> > >>>
> > >>> (current logo is found at
> > >>> http://www.apache.org/logos/comdev-test/#calcite for reference)
> > >>>
> > >>> If you like it, it's hereby ALv2 so feel free to use it.
> > >>> If you want changes, or maybe a logo contest, that's also a-okay!
> Just
> > >>> let me know if you have feedback, and remember to CC me if so, as I'm
> > >>> not on this mailing list.
> > >>>
> > >>> With warm regards,
> > >>> Daniel.
> > >>>
> > >
> >
> >
>

Re: JDK 8 syntax

[Vova Vysotskyi]

Sure, I'll prepare the fix, just wanted to share good news :)

Kind regards,
Volodymyr Vysotskyi


On Tue, Aug 28, 2018 at 8:41 PM Julian Hyde  wrote:

> Excellent. Can you commit the fix please, Vova?
>
> > On Aug 28, 2018, at 10:34 AM, Vova Vysotskyi  wrote:
> >
> > Hi all,
> >
> > Janino issue  with
> > this "strange" default method was fixed, so now we can revert the
> temporary
> > fix made in CALCITE-2261
> >  and update Janino
> > version to 3.0.9.
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> >
> > On Sat, Apr 21, 2018 at 11:27 AM Enrico Olivelli 
> > wrote:
> >
> >> Patch merged!
> >>
> >> Welcome to java 8 !
> >>
> >> Enrico
> >>
> >> Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha
> >> scritto:
> >>
> >>> Issue
> >>> https://issues.apache.org/jira/browse/CALCITE-2261
> >>>
> >>> Patch
> >>> https://github.com/apache/calcite/pull/667
> >>>
> >>> Cheers
> >>> Enrico
> >>>
> >>>
> >>> 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
> >>>
>  Vova,
>  I tried to add some "default" methods and all tests are passing (maybe
>  you already saw this).
>  Thank you !
> 
>  I will be happy to contribute my patch as it is really simple and I
> have
>  it on my laptop
> 
>  Enrico
> 
> 
>  2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
> 
> > Taking a step to the side of a workaround, the current version of
> >> Janino
> > prefers default methods instead of "abstract", so we may declare
> > *SchemaPlus.getSubSchema()* method as default and it will help to
> >> choose
> > this method instead of the method from the parent interface :)
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> > 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
> >
> >> I have tried to add an 'unwrap' method to Schema but then Janino
> >> keeps
> >> breaking for other similar reasons about method overriding with
> > narrower
> >> return types.
> >>
> >> I guess it will be an hard task to adapt Calcite code.
> >> The approach of working on Janino is better.
> >>
> >> Enrico
> >>
> >> Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
> >> scritto:
> >>
> >>>
> >>>
> >>> Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> > scritto:
> >>>
>  I have reproduced it in Janino only and created the issue:
>  https://github.com/janino-compiler/janino/issues/47
> >>>
> >>>
> >>> Great work Vova,
> >>> Thank you
> >>>
> >>> Enrico
> >>>
> >>>
> >>>
> 
> 
> 
>  Kind regards,
>  Volodymyr Vysotskyi
> 
>  2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
> 
> > Ok, I will try to prepare a test case and will log a bug on
> >> Janino
> >> soon.
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> >
> >> Vova,
> >>
> >> Thanks for doing the research. Your explanation sounds very
> > plausible
> >> (I suspected default methods, too). Can you please log a bug on
> >> JANINO? https://github.com/janino-compiler/janino/issues Arno,
> > the
> >> project maintainer, has been very good to us over the years.
> >>
> >> Julian
> >>
> >>
> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
> >> eolive...@gmail.com>
> >> wrote:
> >>> Il sab 14 apr 2018, 18:20 Enrico Olivelli <
> >> eolive...@gmail.com>
> > ha
> >> scritto:
> >>>
> 
> 
>  Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
> > ha
> >> scritto:
> 
> > Hi all,
> >
> > I think the reason for this issue is that at the compile
> > stage
> >> was
> >> assumed
> > that *getSubSchema()* method returns *Schema *inheritor,
> >> but
> > not
> > *SchemaPlus*.
> > But the interesting thing is that with Java 8, methods list
> > of
> > *SchemaPlus *interface
> > contains default *getSubSchema()* method.
> > It may be observed by executing this code:
> > *Method[] declaredMethods =
> >
> >
> >> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> >> laredMethods();*
> > *for (Method m : declaredMethods) {*
> > *  if (m.getName().equals("getSubSchema")) {*
> > *System.out.println(m);*
> > *  }*
> > *}*
> >
> > Its output:
> >
> > *public default org.apache.calcite.schema.Schema
> >
> 
> >> 

Re: Calcite contributions

[Julian Hyde]

Vladimir,

I think Michael is being a bit too nice. Your behavior was extremely rude.

It does seem that you were technically correct in this case. But we require 
civility in this community.

Julian


> On Aug 28, 2018, at 11:11 AM, Michael Mior  wrote:
> 
> I understand that when there are issues with trivial fixes, it's sometimes
> much easier to just fix them yourself. I think it's still beneficial if
> people are willing to work with the original contributor to fix things, but
> I understand not everyone will be able to invest that time. If an alternate
> fix is made that supersedes a patch which was contributed, I still think
> this should be communicated to the original contributor along with a link
> to the fix. This at least gives the person an opportunity to learn.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le mar. 28 août 2018 à 09:56, Vladimir Sitnikov 
> a écrit :
> 
>> Michael> But the default in those cases should hopefully be to work with
>> the
>> Michael>original contributor to make any necessary changes or in some cases
>> explain
>> 
>> Please clarify if you mean that BOTH trivial and non-trivial cases to be
>> handled in exactly the same way.
>> 
>> Vladimir
>> 

Re: Calcite contributions

[Michael Mior]

I understand that when there are issues with trivial fixes, it's sometimes
much easier to just fix them yourself. I think it's still beneficial if
people are willing to work with the original contributor to fix things, but
I understand not everyone will be able to invest that time. If an alternate
fix is made that supersedes a patch which was contributed, I still think
this should be communicated to the original contributor along with a link
to the fix. This at least gives the person an opportunity to learn.

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



Le mar. 28 août 2018 à 09:56, Vladimir Sitnikov 
a écrit :

> Michael> But the default in those cases should hopefully be to work with
> the
> Michael>original contributor to make any necessary changes or in some cases
> explain
>
> Please clarify if you mean that BOTH trivial and non-trivial cases to be
> handled in exactly the same way.
>
> Vladimir
>

Re: calcite document issue

[Michael Mior]

If you have specific suggestions on where the documentation should be
extended or improved, we would welcome those (especially if they come with
a pull request :) As it is, it's unclear what documentation you're
suggesting be added.

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



Le mar. 28 août 2018 à 13:25, 毛秀庆  a écrit :

> Hi: 你们好!
>
> (I'm work using java )
>
>
> first , calcite is complex ,but document is so lack ;
>
>
> calcite-core has many classes, i think should add class UML , the core
> concept introduce , develop document ;
>
>
> i look over the source code, my brain has no clue ;
>
>
> more deep , more  doc ;

Re: [jira] [Comment Edited] (CALCITE-2495) Rework URL->File conversion in tests

[Sergey Nuyanzin]

>> Can someone please test this on Windows before we submit?

was able to pass mvn clean install on Windows however made several changes
to do that
all mentioned in comments for the PR
https://github.com/apache/calcite/pull/807

On Tue, Aug 28, 2018 at 8:11 PM Vladimir Sitnikov (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/CALCITE-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595314#comment-16595314
> ]
>
> Vladimir Sitnikov edited comment on CALCITE-2495 at 8/28/18 5:10 PM:
> -
>
> {quote}You mis-spelled "handle" as "hanle".{quote}
> -Where-
> Nevermind, I've fixed that in signatures.txt
>
>
> was (Author: vladimirsitnikov):
> {quote}You mis-spelled "handle" as "hanle".{quote}
> Where?
>
> > Rework URL->File conversion in tests
> > 
> >
> > Key: CALCITE-2495
> > URL: https://issues.apache.org/jira/browse/CALCITE-2495
> > Project: Calcite
> >  Issue Type: Bug
> >Reporter: Vladimir Sitnikov
> >Assignee: Julian Hyde
> >Priority: Major
> >
> > {{URL.getPath()}} produces %20 when path contains spaces.
> > I suggest to rework all the uses of {{getResource()...}} to use
> {{Sources.of(URL)}} so there's single -point of failure- way to convert URL
> to File.
> > This resolves Apache CI which happens to have a space in folder name.
> > For the record:
> > 1) {{URL.getPath()}} produces %20, so it is added to forbidden signatures
> > 2) {{Paths.get(url.toURI()).toFile()}} almost works, however it fails
> with URL is not hierarchical for {{new URL("file:test.java")}}
> > 3) {{new File(URL.toURI()}} is worse than #2
> > 4) {{URLDecoder}} must not be used to decode %20, since it will convert
> {{+}} to spaces as well, thus it will corrupt {{test.c++}}
> > 5) It looks like {{url.toURI().getSchemeSpecificPart())}} properly
> handles "opaque" URIs (which are relative {{file:test.java}} kind of URLs)
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>


-- 
Best regards,
Sergey

Re: JDK 8 syntax

[Julian Hyde]

Excellent. Can you commit the fix please, Vova?

> On Aug 28, 2018, at 10:34 AM, Vova Vysotskyi  wrote:
> 
> Hi all,
> 
> Janino issue  with
> this "strange" default method was fixed, so now we can revert the temporary
> fix made in CALCITE-2261
>  and update Janino
> version to 3.0.9.
> 
> Kind regards,
> Volodymyr Vysotskyi
> 
> 
> On Sat, Apr 21, 2018 at 11:27 AM Enrico Olivelli 
> wrote:
> 
>> Patch merged!
>> 
>> Welcome to java 8 !
>> 
>> Enrico
>> 
>> Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha
>> scritto:
>> 
>>> Issue
>>> https://issues.apache.org/jira/browse/CALCITE-2261
>>> 
>>> Patch
>>> https://github.com/apache/calcite/pull/667
>>> 
>>> Cheers
>>> Enrico
>>> 
>>> 
>>> 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
>>> 
 Vova,
 I tried to add some "default" methods and all tests are passing (maybe
 you already saw this).
 Thank you !
 
 I will be happy to contribute my patch as it is really simple and I have
 it on my laptop
 
 Enrico
 
 
 2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
 
> Taking a step to the side of a workaround, the current version of
>> Janino
> prefers default methods instead of "abstract", so we may declare
> *SchemaPlus.getSubSchema()* method as default and it will help to
>> choose
> this method instead of the method from the parent interface :)
> 
> Kind regards,
> Volodymyr Vysotskyi
> 
> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
> 
>> I have tried to add an 'unwrap' method to Schema but then Janino
>> keeps
>> breaking for other similar reasons about method overriding with
> narrower
>> return types.
>> 
>> I guess it will be an hard task to adapt Calcite code.
>> The approach of working on Janino is better.
>> 
>> Enrico
>> 
>> Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
>> scritto:
>> 
>>> 
>>> 
>>> Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> scritto:
>>> 
 I have reproduced it in Janino only and created the issue:
 https://github.com/janino-compiler/janino/issues/47
>>> 
>>> 
>>> Great work Vova,
>>> Thank you
>>> 
>>> Enrico
>>> 
>>> 
>>> 
 
 
 
 Kind regards,
 Volodymyr Vysotskyi
 
 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
 
> Ok, I will try to prepare a test case and will log a bug on
>> Janino
>> soon.
> 
> Kind regards,
> Volodymyr Vysotskyi
> 
> 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> 
>> Vova,
>> 
>> Thanks for doing the research. Your explanation sounds very
> plausible
>> (I suspected default methods, too). Can you please log a bug on
>> JANINO? https://github.com/janino-compiler/janino/issues Arno,
> the
>> project maintainer, has been very good to us over the years.
>> 
>> Julian
>> 
>> 
>> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
>> eolive...@gmail.com>
>> wrote:
>>> Il sab 14 apr 2018, 18:20 Enrico Olivelli <
>> eolive...@gmail.com>
> ha
>> scritto:
>>> 
 
 
 Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
> ha
>> scritto:
 
> Hi all,
> 
> I think the reason for this issue is that at the compile
> stage
>> was
>> assumed
> that *getSubSchema()* method returns *Schema *inheritor,
>> but
> not
> *SchemaPlus*.
> But the interesting thing is that with Java 8, methods list
> of
> *SchemaPlus *interface
> contains default *getSubSchema()* method.
> It may be observed by executing this code:
> *Method[] declaredMethods =
> 
> 
>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
>> laredMethods();*
> *for (Method m : declaredMethods) {*
> *  if (m.getName().equals("getSubSchema")) {*
> *System.out.println(m);*
> *  }*
> *}*
> 
> Its output:
> 
> *public default org.apache.calcite.schema.Schema
> 
 
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> *public abstract org.apache.calcite.schema.SchemaPlus
> 
 
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> 
> The output of the same code for Java 7:
> 
> *public abstract org.apache.calcite.schema.SchemaPlus
> 
 
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*

Re: Maven wrapper

[Julian Hyde]

> On Aug 28, 2018, at 8:10 AM, Josh Elser  wrote:
> 
> Is it worthwhile to share the details of that situation with the community 
> (or are the specifics you provided all that's really relevant)? Asking to 
> better understand if there is some legitimate criticism of what Maven lets 
> you do, or if it's something we can make better in Calcite itself.

This particular case was a consultant for my company for whom I was building a 
custom version of Calcite. The consultant is technical and uses git all the 
time, has a JVM installed on his machine (mainly for JRuby), but does not do 
Java development, therefore does not have maven. 

Since his machine is macOS it was straightforward to do “brew install maven”. 
(Which took about 20 minutes, because he first had to upgrade home-brew.)

Clearly it was not that hard for him to install maven, but if we used mvnw we 
could remove even that friction.

> As long as we don't create a schism where some things can only be done by 
> mvnw, I'm OK with this change.

I promise that won’t happen.

I believe that if you have mvn installed, mvnw will use it. Therefore most 
developers will continue to use the same path, regardless of whether they type 
“mvn” or “./mvnw”. I will continue to type “mvn”.

Julan

Re: JDK 8 syntax

[Vova Vysotskyi]

Hi all,

Janino issue  with
this "strange" default method was fixed, so now we can revert the temporary
fix made in CALCITE-2261
 and update Janino
version to 3.0.9.

Kind regards,
Volodymyr Vysotskyi


On Sat, Apr 21, 2018 at 11:27 AM Enrico Olivelli 
wrote:

> Patch merged!
>
> Welcome to java 8 !
>
> Enrico
>
> Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha
> scritto:
>
> > Issue
> > https://issues.apache.org/jira/browse/CALCITE-2261
> >
> > Patch
> > https://github.com/apache/calcite/pull/667
> >
> > Cheers
> > Enrico
> >
> >
> > 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
> >
> >> Vova,
> >> I tried to add some "default" methods and all tests are passing (maybe
> >> you already saw this).
> >> Thank you !
> >>
> >> I will be happy to contribute my patch as it is really simple and I have
> >> it on my laptop
> >>
> >> Enrico
> >>
> >>
> >> 2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
> >>
> >>> Taking a step to the side of a workaround, the current version of
> Janino
> >>> prefers default methods instead of "abstract", so we may declare
> >>> *SchemaPlus.getSubSchema()* method as default and it will help to
> choose
> >>> this method instead of the method from the parent interface :)
> >>>
> >>> Kind regards,
> >>> Volodymyr Vysotskyi
> >>>
> >>> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
> >>>
> >>> > I have tried to add an 'unwrap' method to Schema but then Janino
> keeps
> >>> > breaking for other similar reasons about method overriding with
> >>> narrower
> >>> > return types.
> >>> >
> >>> > I guess it will be an hard task to adapt Calcite code.
> >>> > The approach of working on Janino is better.
> >>> >
> >>> > Enrico
> >>> >
> >>> > Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
> >>> > scritto:
> >>> >
> >>> > >
> >>> > >
> >>> > > Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> >>> scritto:
> >>> > >
> >>> > >> I have reproduced it in Janino only and created the issue:
> >>> > >> https://github.com/janino-compiler/janino/issues/47
> >>> > >
> >>> > >
> >>> > > Great work Vova,
> >>> > > Thank you
> >>> > >
> >>> > > Enrico
> >>> > >
> >>> > >
> >>> > >
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >> Kind regards,
> >>> > >> Volodymyr Vysotskyi
> >>> > >>
> >>> > >> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
> >>> > >>
> >>> > >> > Ok, I will try to prepare a test case and will log a bug on
> Janino
> >>> > soon.
> >>> > >> >
> >>> > >> > Kind regards,
> >>> > >> > Volodymyr Vysotskyi
> >>> > >> >
> >>> > >> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> >>> > >> >
> >>> > >> >> Vova,
> >>> > >> >>
> >>> > >> >> Thanks for doing the research. Your explanation sounds very
> >>> plausible
> >>> > >> >> (I suspected default methods, too). Can you please log a bug on
> >>> > >> >> JANINO? https://github.com/janino-compiler/janino/issues Arno,
> >>> the
> >>> > >> >> project maintainer, has been very good to us over the years.
> >>> > >> >>
> >>> > >> >> Julian
> >>> > >> >>
> >>> > >> >>
> >>> > >> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
> >>> > eolive...@gmail.com>
> >>> > >> >> wrote:
> >>> > >> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli <
> eolive...@gmail.com>
> >>> ha
> >>> > >> >> scritto:
> >>> > >> >> >
> >>> > >> >> >>
> >>> > >> >> >>
> >>> > >> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
> >>> ha
> >>> > >> >> scritto:
> >>> > >> >> >>
> >>> > >> >> >>> Hi all,
> >>> > >> >> >>>
> >>> > >> >> >>> I think the reason for this issue is that at the compile
> >>> stage
> >>> > was
> >>> > >> >> assumed
> >>> > >> >> >>> that *getSubSchema()* method returns *Schema *inheritor,
> but
> >>> not
> >>> > >> >> >>> *SchemaPlus*.
> >>> > >> >> >>> But the interesting thing is that with Java 8, methods list
> >>> of
> >>> > >> >> >>> *SchemaPlus *interface
> >>> > >> >> >>> contains default *getSubSchema()* method.
> >>> > >> >> >>> It may be observed by executing this code:
> >>> > >> >> >>> *Method[] declaredMethods =
> >>> > >> >> >>>
> >>> > >> >> >>>
> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> >>> > >> >> laredMethods();*
> >>> > >> >> >>> *for (Method m : declaredMethods) {*
> >>> > >> >> >>> *  if (m.getName().equals("getSubSchema")) {*
> >>> > >> >> >>> *System.out.println(m);*
> >>> > >> >> >>> *  }*
> >>> > >> >> >>> *}*
> >>> > >> >> >>>
> >>> > >> >> >>> Its output:
> >>> > >> >> >>>
> >>> > >> >> >>> *public default org.apache.calcite.schema.Schema
> >>> > >> >> >>>
> >>> > >>
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >>> > >> >> >>>
> >>> > >>
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>> > >> >> >>>
> >>> > >> >> >>> The output of the same code for Java 7:
> >>> > >> >> >>>
> >>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >>> > >> >> >>>
> >>> > >>
> 

calcite document issue

[毛秀庆]

Hi: 你们好! 
  
(I'm work using java )


first , calcite is complex ,but document is so lack ;


calcite-core has many classes, i think should add class UML , the core concept 
introduce , develop document ;


i look over the source code, my brain has no clue ; 


more deep , more  doc ; 

Calcite Jenkins fails due to spaces in folder names

[Vladimir Sitnikov]

Hi,

Jenkins jobs fail due to %20 in the file path.
CI failure holds -SNAPSHOT releases from being published.

The good news is it looks like there's a solution.

https://stackoverflow.com/a/17870390/1261287 suggests Paths.get
(uri).toFile(), however that fails for "file:test.txt" kind of URLs
Apparently uri.getSchemeSpecificPart() extracts *decoded* file name out of
"file:test.txt", so both methods seem to cover all the cases.

The PR is https://github.com/apache/calcite/pull/807, JIRA is
https://issues.apache.org/jira/browse/CALCITE-2495

It would be great if the change could get a review or two.
On the other hand, I'm sure it could be committed as is since it is more or
less small build-script tuning kind of change (modulo various operating
systems)

The idea is to implement URL handling it in Sources.of(URL), and reuse the
class everywhere.
On top of that, I add URL.getPath() to the list of forbidden signatures (it
returns encoded path, so it is hard to use properly).

Note: the PR touches lots of various adapters, however those are mostly
mechanical changes of URL.getPath to Sources.of(URL).file()

Vladimir

Re: Maven wrapper

[Josh Elser]

Is it worthwhile to share the details of that situation with the 
community (or are the specifics you provided all that's really 
relevant)? Asking to better understand if there is some legitimate 
criticism of what Maven lets you do, or if it's something we can make 
better in Calcite itself.


As long as we don't create a schism where some things can only be done 
by mvnw, I'm OK with this change. Hovering somewhere around a "0".


On 8/27/18 9:41 PM, Julian Hyde wrote:

Re-opening a discussion from earlier this year (and logged as 
https://issues.apache.org/jira/browse/CALCITE-2112 
).

I have changed my mind on this issue. I encountered a user today for whom 
getting a valid version of maven was a significant obstacle. I am now +1 — I 
think it would be beneficial to include mvnw and mvnw.bat in the source 
distribution, and use them in our default build instructions.

I do not think it increases complexity. Advanced users can use “mvn” if they 
choose, but the default instructions would mention only “./mvnw”.

We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar. mvnw 
and mvnw.bat work fine without them. As they make release votes more 
complicated, I think we should exclude these.

There were a mixture or -1, -0 and +1 in the original thread. Has anyone else 
changed position?

Julian



On Jan 2, 2018, at 5:01 PM, Julian Hyde  wrote:

We already have a tool that provides a container for the whole build process. 
That tool is maven. I do not recall a time where someone had problems because 
they had the wrong version of maven installed; so this is a non-problem.

I’ve written C/C++ projects before (using autoconf, libtool, mingw etc.), and 
thank heavens we don’t have their problems.

If we were to use a wrapper, we’d either have to get the wrapper from an 
external repo, or we’d have to distribute the wrapper. For the first, we’ve 
just shifted the version-management problem; for the second, we’d be 
distributing our own tool-chain, including binaries (non-source files), which 
is problematic for an open source project.

Julian



On Jan 2, 2018, at 3:31 PM, Josh Elser  wrote:

+1 to the simplicity.

But, to Vladimir's issues (thx btw), maybe we can solve some of those 
pain-points another way? I've seen some projects (notably, those with 
compilation of C/C++ code) provide a Dockerfile that can create an environment 
capable of building that native code.

It seems like a lot of the things Vladimir cites could be solved by a similar 
approach which would keep us on a single build tool (instead, providing a 
ready-made environment to build without polluting anything else).

I'd be OK with that approach if someone wanted to make that work.

On 1/2/18 5:03 PM, Julian Hyde wrote:

Yes.
But I claim that adding mvnw to the picture makes things more complicated for 
the typical user, because there are now more options to understand.
Julian

On Jan 2, 2018, at 2:00 PM, Michael Mior  wrote:

Even if we do include mvnw, isn't it still possible to use a compatible mvn
directly?

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

2018-01-02 15:35 GMT-05:00 Julian Hyde :


True, but for 2 and 3 it’s not much of a hardship to type

$ /usr/local/maven-x.y.z/bin/mvn -s my-settings.xml target

rather than

$ mvn target

And for 1, I claim that typing “mvn” is less surprising to most people
than typing “mvnw”. Because most people who build java code these days are
familiar with mvn.

Julian







On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <

sitnikov.vladi...@gmail.com> wrote:



Multiple versions of Maven can be installed side-by-side (and we don't

have esoteric requirements). As such, I don't see the need for such a
change

The reasons could include:
1) Simplified Apache Maven installation for those who have no experience
with it
2) Having multiple settings.xml files (e.g. if corporate rules requires
certain settings.xml that is incompatible with Apache Calcite

settings.xml)

3) Simplified management of multiple Apache Maven versions. In the same
way, corporate rules might require specific mvn version (outdated due to
plugins, etc), so that version would likely be the default.

Vladimir

code review: CALCITE-2485. Wrong single projection in Elastic adapter

[Andrei Sereda]

Hello,

Can somebody pls take a look at PR801
 (CALCITE-2485
). It is a fix for ES
adapter bug (bad logic for single element projections).

Thank you,
Andrei.

Re: graphql query to sql query with Calcite ?

[Stamatis Zampetakis]

Hi Eugen,

You can have a look at RelBuilderTest to see how to instantiate a
RelBuilder.
To create a Calcite Schema you may also take inspiration from the following
method:
org.apache.calcite.test.CalciteAssert#addSchema

Best,
Stamatis


Στις Τρί, 28 Αυγ 2018 στις 10:31 π.μ., ο/η Eugen Stan 
έγραψε:

> Hello Julian,
>
> Thank you for the pointers. It is very helpful and I have started
> working on the project. I'm currently discovering Calcite API.
>
> Any ideas on where I can find documentation to create an In memory
> schema so I can pass it to RelBuilder ?
>
> I did not find much on the website. I'll use graphql-java to parse the
> query and build an "AST".
>
> My goal is to make it work for the simple graphql example with StarWars :).
>
> Once this is done I will target PostgreSQL. One interesting feature of
> PostgreSQL is Foreign Data Wrappers [fdw] .It makes multiple databases
> visible as one, including PostgreSQL and it can make the query planning
> for me :D .
>
> Thanks,
>
> Eugen
>
> [fdw] https://wiki.postgresql.org/wiki/Foreign_data_wrappers
>
> On 24.08.2018 00:32, Julian Hyde wrote:
> > I’d call that a "GraphQL front-end for Calcite". (SQL is our main front
> end, but other front-ends include linq4j and I gather there are other query
> languages in commercial products, e.g. Stardog uses Calcite to translate
> SPARQL to SQL[1].)
> >
> > I think this is a good fit for Calcite, and would support it. Should it
> be a module in Calcite, or a standalone project that uses Calcite? Both are
> reasonable options.
> >
> > In case folks on the dev list are not familiar with GraphQL, I will
> point out that it is NOT a query language for graph databases (as are
> Cypher, SPARQL, Gremlin). But it is exceedingly good at running queries on
> data sources with nested data and producing results to power web
> applications. And it is becoming extremely popular.
> >
> > My thumbnail sketch of the architecture: write (or better, re-use) a
> GraphQL parser and semantic analyzer. Take the validated GraphQL AST and
> convert it into Calcite relational algebra (probably using RelBuilder[2]).
> Then use RelToSqlConverter to convert relational algebra to SQL.
> RelToSqlConverter handles differences in dialect, and is getting better all
> the time.
> >
> > Julian
> >
> > [1] https://www.stardog.com/blog/virtual-graphs-in-stardog-5/ <
> https://www.stardog.com/blog/virtual-graphs-in-stardog-5/>
> >
> > [2] https://calcite.apache.org/docs/algebra.html#algebra-builder <
> https://calcite.apache.org/docs/algebra.html#algebra-builder>
> >
> >
> >> On Aug 21, 2018, at 10:21 PM, Eugen Stan  wrote:
> >>
> >> Hello,
> >>
> >> TLDR:
> >>
> >> I'm wondering if I can integrate Calcite with [graphql-java] and use
> >> Calcite to transform a graphql query into an SQL query and send it
> >> directly to the database.
> >>
> >> Furthermore, I'm curious if I can use Calcite's adapters to emulate an
> >> SQL layer on top of other remote services and leverage the query planner
> >> from Calcite to build smart/optimal queries.
> >>
> >> There is prior art to this: a project called [join-monster] that does
> >> this for JS. See [join-monster-7-min] video for a short description.
> >>
> >> The process to go from graphql query to SQL query is described in
> >> [join-monster-process] and it's quite short.
> >>
> >> Longer version
> >>
> >> I'm working on a GraphQL API for a SaaS platform. Right now we are
> >> facing with a common problem in GraphQL: one query for a graph of
> >> objects will turn to N+1 queries on the back-end data-store. There is a
> >> lot of literature on this on the internet and also descibed in
> >> [data-loader] and [join-monster].
> >>
> >> Now, one solution for this problem is to use [data-loader]  - to cache
> >> objects. This works for some, and it is kind of the only solution for
> >> remote data stores (other http API endpoints).
> >>
> >> My initial objective is to transform the AST that graphql-java builds
> >> into an AST for SQL and push this SQL to one database.
> >>
> >> I believe Calcite can help with this and I'm reaching out to the
> >> community since I'm not familiar with the project and the features and
> >> limitations it has.
> >>
> >> Can Calcite help me transform the GraphQL query AST to an SQL AST?
> >>
> >> Should I look into this or should I go straight to something like ANTLR.
> >> I know there is a definition for [graphql-java-antlr] . I'm asking this
> >> to know if it has features that could help me or could block me?
> >>
> >> Features that could help I imagine is the [SQL-grammer] ?
> >>
> >>
> >> Thank you,
> >>
> >> Eugen
> >>
> >>
> >> [data-loader] https://github.com/facebook/dataloader
> >>
> >> [graphql-java] https://github.com/graphql-java/graphql-java/
> >>
> >> [join-monster] https://join-monster.readthedocs.io/en/latest/
> >>
> >> [join-monster-7-min] https://www.youtube.com/watch?v=Y7AdMIuXOgs
> >>
> >> [join-monster-process]
> >> 

Re: Maven wrapper

[Vladimir Sitnikov]

Just to clarify: I was always +1 re Maven wrapper.

PS. Hopefully it is a small step forward to Gradle wrapper :)
Vladimir

Re: Calcite contributions

[Vladimir Sitnikov]

Michael> But the default in those cases should hopefully be to work with the
Michael>original contributor to make any necessary changes or in some cases
explain

Please clarify if you mean that BOTH trivial and non-trivial cases to be
handled in exactly the same way.

Vladimir

Re: Maven wrapper

[Michael Mior]

I was originally -0 which I will change to +0 (I could probably be
convinced to be +1). I don't see any major issue in including since it's
just two files that we can easily remove later if we choose to. If we do
this, we definitely should have the default instructions use mvnw as Julian
suggested and update CI to use it as well.

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



Le lun. 27 août 2018 à 21:41, Julian Hyde  a écrit :

> Re-opening a discussion from earlier this year (and logged as
> https://issues.apache.org/jira/browse/CALCITE-2112 <
> https://issues.apache.org/jira/browse/CALCITE-2112>).
>
> I have changed my mind on this issue. I encountered a user today for whom
> getting a valid version of maven was a significant obstacle. I am now +1 —
> I think it would be beneficial to include mvnw and mvnw.bat in the source
> distribution, and use them in our default build instructions.
>
> I do not think it increases complexity. Advanced users can use “mvn” if
> they choose, but the default instructions would mention only “./mvnw”.
>
> We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar.
> mvnw and mvnw.bat work fine without them. As they make release votes more
> complicated, I think we should exclude these.
>
> There were a mixture or -1, -0 and +1 in the original thread. Has anyone
> else changed position?
>
> Julian
>
>
> > On Jan 2, 2018, at 5:01 PM, Julian Hyde  wrote:
> >
> > We already have a tool that provides a container for the whole build
> process. That tool is maven. I do not recall a time where someone had
> problems because they had the wrong version of maven installed; so this is
> a non-problem.
> >
> > I’ve written C/C++ projects before (using autoconf, libtool, mingw
> etc.), and thank heavens we don’t have their problems.
> >
> > If we were to use a wrapper, we’d either have to get the wrapper from an
> external repo, or we’d have to distribute the wrapper. For the first, we’ve
> just shifted the version-management problem; for the second, we’d be
> distributing our own tool-chain, including binaries (non-source files),
> which is problematic for an open source project.
> >
> > Julian
> >
> >
> >> On Jan 2, 2018, at 3:31 PM, Josh Elser  wrote:
> >>
> >> +1 to the simplicity.
> >>
> >> But, to Vladimir's issues (thx btw), maybe we can solve some of those
> pain-points another way? I've seen some projects (notably, those with
> compilation of C/C++ code) provide a Dockerfile that can create an
> environment capable of building that native code.
> >>
> >> It seems like a lot of the things Vladimir cites could be solved by a
> similar approach which would keep us on a single build tool (instead,
> providing a ready-made environment to build without polluting anything
> else).
> >>
> >> I'd be OK with that approach if someone wanted to make that work.
> >>
> >> On 1/2/18 5:03 PM, Julian Hyde wrote:
> >>> Yes.
> >>> But I claim that adding mvnw to the picture makes things more
> complicated for the typical user, because there are now more options to
> understand.
> >>> Julian
>  On Jan 2, 2018, at 2:00 PM, Michael Mior  wrote:
> 
>  Even if we do include mvnw, isn't it still possible to use a
> compatible mvn
>  directly?
> 
>  --
>  Michael Mior
>  mm...@apache.org
> 
>  2018-01-02 15:35 GMT-05:00 Julian Hyde :
> 
> > True, but for 2 and 3 it’s not much of a hardship to type
> >
> > $ /usr/local/maven-x.y.z/bin/mvn -s my-settings.xml target
> >
> > rather than
> >
> > $ mvn target
> >
> > And for 1, I claim that typing “mvn” is less surprising to most
> people
> > than typing “mvnw”. Because most people who build java code these
> days are
> > familiar with mvn.
> >
> > Julian
> >
> >
> >
> >
> >
> >
> >> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> wrote:
> >>
> >>> Multiple versions of Maven can be installed side-by-side (and we
> don't
> >> have esoteric requirements). As such, I don't see the need for such
> a
> >> change
> >>
> >> The reasons could include:
> >> 1) Simplified Apache Maven installation for those who have no
> experience
> >> with it
> >> 2) Having multiple settings.xml files (e.g. if corporate rules
> requires
> >> certain settings.xml that is incompatible with Apache Calcite
> > settings.xml)
> >> 3) Simplified management of multiple Apache Maven versions. In the
> same
> >> way, corporate rules might require specific mvn version (outdated
> due to
> >> plugins, etc), so that version would likely be the default.
> >>
> >> Vladimir
> >
> >
> >
>
>

Re: Calcite contributions

[Michael Mior]

I do think it would have been more productive if this discussion had
happened earlier. I generally expect for non-trivial PRs that the first
version have issues (certainly most/all of mine do.) As committers/PMC
members, we do have a role as gatekeepers and we shouldn't merge PRs with
issues. But the default in those cases should hopefully be to work with the
original contributor to make any necessary changes or in some cases explain
why the PR is likely to never be merged (because of some inherent issue to
the approach).

Unfortunately, this often takes more time and effort than just fixing
things ourselves, but that's part of what's necessary for building a
healthy and sustainable open source project.

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



Le mar. 28 août 2018 à 08:31, Zoltan Haindrich  a écrit :

> Hello,
>
> I've found a simplification issue a while ago; written an ignored test for
> it - and opened a new jira to have the fix its own ticket:
> https://issues.apache.org/jira/browse/CALCITE-2327 - because it was not
> connected to the actual ticket.
>
> * I've submitted a patch to disable this oversimplification because that
> seemed to be the right move to me.
> * The review process became stuck after a while...
> * Today I've got a mail that my PR is got closed by Vladimir Sitnikov...I
> went to see what's up...
> * Seems like Vladimir have just committed a different patch - and closed
> the ticket (which is still assigned to me) and that's it...
> * I feel that it would have been better to at least contact me prior to
> just throwing a completely different patch at the problem - ...because
> unfortunately this new patch
> still contains an bug.
>
> I've looked at the last few commits to see if this a "pattern": for
> CALCITE-2271 something similar happened...Alexey Makhmutov have submitted a
> PR in April; 2 days ago
> Vladimir have continued and submitted his own version of it.
>
> Sorry, but I don't think the above process is "right"...
>
> cheers,
> Zoltan
>

[jira] [Created] (CALCITE-2496) EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE must be zero

[Sergey Nuyanzin (JIRA)]

Sergey Nuyanzin created CALCITE-2496:


 Summary: EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE 
must be zero
 Key: CALCITE-2496
 URL: https://issues.apache.org/jira/browse/CALCITE-2496
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde


There was already a similar issue CALCITE-2324 but I'm sorry I did not take 
into account 3 time units. Now I want to cover them here. So all existing 
Timeunits from {{org.apache.calcite.avatica.util.TimeUnit}} which are less than 
a day will be covered



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

Re: Calcite contributions

[Atri Sharma]

On Tue, Aug 28, 2018 at 6:09 PM Vladimir Sitnikov
 wrote:

> Initial analysis by Alexey was not right, so he implemented a wrong
> solution. That happens when people try to fix unfamiliar codebases.

I am completely out of line here, but this statement sounds pretty
detrimental to any potential future contributors who would want to
start small. If a contributor is going in the wrong path, it would be
helpful to point it out to him and *suggested* help him in the right
direction, rather than steam rolling his efforts. Even if a committer
wishes to re do a patch, he/she should point out the mistakes in the
contributors patch before posting a different patch.

Re: Calcite contributions

[Vladimir Sitnikov]

Zoltan>...because unfortunately this new patch  still contains an bug.

Could I please correct you a bit?
The patch did solve the issue that is represented in the issue description.
The patch did pass all the tests you had by that moment.

So "still contains a bug" is more like "there are uncovered cases".

Zoltan>* I've submitted a patch to disable this oversimplification because
that seemed to be the right move to me.

That is the culprit. Your analysis was too pessimistic, so you decided to
remove a feature rather than implement a bug fix.
There are cases when it is safer to just remove half-backed feature,
however 2327 is not of that kind.

>CALCITE-2271 something similar happened...Alexey Makhmutov

Initial analysis by Alexey was not right, so he implemented a wrong
solution. That happens when people try to fix unfamiliar codebases.

Vladimir

Calcite contributions

[Zoltan Haindrich]

Hello,

I've found a simplification issue a while ago; written an ignored test for it - 
and opened a new jira to have the fix its own ticket:
https://issues.apache.org/jira/browse/CALCITE-2327 - because it was not 
connected to the actual ticket.

* I've submitted a patch to disable this oversimplification because that seemed 
to be the right move to me.
* The review process became stuck after a while...
* Today I've got a mail that my PR is got closed by Vladimir Sitnikov...I went 
to see what's up...
* Seems like Vladimir have just committed a different patch - and closed the 
ticket (which is still assigned to me) and that's it...
* I feel that it would have been better to at least contact me prior to just throwing a completely different patch at the problem - ...because unfortunately this new patch 
still contains an bug.


I've looked at the last few commits to see if this a "pattern": for CALCITE-2271 something similar happened...Alexey Makhmutov have submitted a PR in April; 2 days ago 
Vladimir have continued and submitted his own version of it.


Sorry, but I don't think the above process is "right"...

cheers,
Zoltan

Calcite-Master - Build # 800 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

[jira] [Created] (CALCITE-2495) Rework URL->File conversion in tests

[Vladimir Sitnikov (JIRA)]

Vladimir Sitnikov created CALCITE-2495:
--

 Summary: Rework URL->File conversion in tests
 Key: CALCITE-2495
 URL: https://issues.apache.org/jira/browse/CALCITE-2495
 Project: Calcite
  Issue Type: Bug
Reporter: Vladimir Sitnikov
Assignee: Julian Hyde


{{URL.getPath()}} produces %20 when path contains spaces.
I suggest to rework all the uses of {{getResource()...}} to use 
{{Sources.of(URL)}} so there's single -point of failure- way to convert URL to 
File.

This resolves Apache CI which happens to have a space in folder name.



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

[GitHub] calcite-avatica-go pull request #27: [CALCITE-2335] Add support for Go modul...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/27


---

[GitHub] calcite-avatica-go pull request #27: [CALCITE-2335] Add support for Go modul...

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/27

[CALCITE-2335] Add support for Go modules and test against Go 1.11



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go go-modules

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/27.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #27


commit e589422c7b0c6fc3eb133a062593d20b5d6802d6
Author: Francis Chuang 
Date:   2018-08-28T10:25:20Z

[CALCITE-2335] Add support for Go modules and test against Go 1.11




---

Calcite-Master - Build # 799 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Calcite-Master - Build # 798 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

[jira] [Created] (CALCITE-2494) RexFieldAccess should implement equals/hashCode

[Vladimir Sitnikov (JIRA)]

Vladimir Sitnikov created CALCITE-2494:
--

 Summary: RexFieldAccess should implement equals/hashCode
 Key: CALCITE-2494
 URL: https://issues.apache.org/jira/browse/CALCITE-2494
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Vladimir Sitnikov
Assignee: Julian Hyde


{{simplify(or(vBool(), vBool()))}} produces which means RexSimplify tried to 
assign different values to the instances of {{?0.bool0}}
{noformat}
java.lang.AssertionError: result mismatch: when applied to {?0.bool0=false, 
?0.bool0=true}, OR(?0.bool0, ?0.bool0) yielded true, and ?0.bool0 yielded false

at org.apache.calcite.rex.RexSimplify.verify(RexSimplify.java:1158)
at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:175)
at 
org.apache.calcite.test.RexProgramTest.checkSimplify2(RexProgramTest.java:149)
at 
org.apache.calcite.test.RexProgramTest.testSimplifyAnd3DynamicParam(RexProgramTest.java:1573)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566){noformat}



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

[GitHub] calcite-avatica-go pull request #26: [CALCITE-2493] Update dependencies

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/26


---

Re: graphql query to sql query with Calcite ?

[Eugen Stan]

Hello Julian,

Thank you for the pointers. It is very helpful and I have started
working on the project. I'm currently discovering Calcite API.

Any ideas on where I can find documentation to create an In memory
schema so I can pass it to RelBuilder ?

I did not find much on the website. I'll use graphql-java to parse the
query and build an "AST". 

My goal is to make it work for the simple graphql example with StarWars :).

Once this is done I will target PostgreSQL. One interesting feature of
PostgreSQL is Foreign Data Wrappers [fdw] .It makes multiple databases
visible as one, including PostgreSQL and it can make the query planning
for me :D .

Thanks,

Eugen

[fdw] https://wiki.postgresql.org/wiki/Foreign_data_wrappers

On 24.08.2018 00:32, Julian Hyde wrote:
> I’d call that a "GraphQL front-end for Calcite". (SQL is our main front end, 
> but other front-ends include linq4j and I gather there are other query 
> languages in commercial products, e.g. Stardog uses Calcite to translate 
> SPARQL to SQL[1].)
>
> I think this is a good fit for Calcite, and would support it. Should it be a 
> module in Calcite, or a standalone project that uses Calcite? Both are 
> reasonable options.
>
> In case folks on the dev list are not familiar with GraphQL, I will point out 
> that it is NOT a query language for graph databases (as are Cypher, SPARQL, 
> Gremlin). But it is exceedingly good at running queries on data sources with 
> nested data and producing results to power web applications. And it is 
> becoming extremely popular. 
>
> My thumbnail sketch of the architecture: write (or better, re-use) a GraphQL 
> parser and semantic analyzer. Take the validated GraphQL AST and convert it 
> into Calcite relational algebra (probably using RelBuilder[2]). Then use 
> RelToSqlConverter to convert relational algebra to SQL. RelToSqlConverter 
> handles differences in dialect, and is getting better all the time.
>
> Julian
>
> [1] https://www.stardog.com/blog/virtual-graphs-in-stardog-5/ 
> 
>
> [2] https://calcite.apache.org/docs/algebra.html#algebra-builder 
> 
>
>
>> On Aug 21, 2018, at 10:21 PM, Eugen Stan  wrote:
>>
>> Hello,
>>
>> TLDR:
>>
>> I'm wondering if I can integrate Calcite with [graphql-java] and use
>> Calcite to transform a graphql query into an SQL query and send it
>> directly to the database.
>>
>> Furthermore, I'm curious if I can use Calcite's adapters to emulate an
>> SQL layer on top of other remote services and leverage the query planner
>> from Calcite to build smart/optimal queries.
>>
>> There is prior art to this: a project called [join-monster] that does
>> this for JS. See [join-monster-7-min] video for a short description.
>>
>> The process to go from graphql query to SQL query is described in
>> [join-monster-process] and it's quite short.
>>
>> Longer version
>>
>> I'm working on a GraphQL API for a SaaS platform. Right now we are
>> facing with a common problem in GraphQL: one query for a graph of
>> objects will turn to N+1 queries on the back-end data-store. There is a
>> lot of literature on this on the internet and also descibed in
>> [data-loader] and [join-monster].
>>
>> Now, one solution for this problem is to use [data-loader]  - to cache
>> objects. This works for some, and it is kind of the only solution for
>> remote data stores (other http API endpoints).
>>
>> My initial objective is to transform the AST that graphql-java builds
>> into an AST for SQL and push this SQL to one database.
>>
>> I believe Calcite can help with this and I'm reaching out to the
>> community since I'm not familiar with the project and the features and
>> limitations it has.
>>
>> Can Calcite help me transform the GraphQL query AST to an SQL AST? 
>>
>> Should I look into this or should I go straight to something like ANTLR.
>> I know there is a definition for [graphql-java-antlr] . I'm asking this
>> to know if it has features that could help me or could block me?
>>
>> Features that could help I imagine is the [SQL-grammer] ? 
>>
>>
>> Thank you,
>>
>> Eugen
>>
>>
>> [data-loader] https://github.com/facebook/dataloader
>>
>> [graphql-java] https://github.com/graphql-java/graphql-java/ 
>>
>> [join-monster] https://join-monster.readthedocs.io/en/latest/
>>
>> [join-monster-7-min] https://www.youtube.com/watch?v=Y7AdMIuXOgs
>>
>> [join-monster-process]
>> https://github.com/acarl005/join-monster/tree/master/src
>>
>> [graphql-java-antlr]
>> https://github.com/graphql-java/graphql-java/tree/master/src/main/antlr 
>>
>> [sql-grammmer] https://calcite.apache.org/docs/reference.html
>>
>>
>



signature.asc
Description: OpenPGP digital signature

Calcite-Master - Build # 797 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

[GitHub] calcite-avatica-go pull request #26: [CALCITE-2493] Update dependencies

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/26

[CALCITE-2493] Update dependencies



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go 
update-dependencies

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/26.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #26


commit 334bc15f92dd5b719b0f58ca8873f6103085984c
Author: Francis Chuang 
Date:   2018-08-28T06:10:53Z

[CALCITE-2493] Update dependencies




---