Re: Dropping support for Guava versions earlier than 14

What about APIs with byte[] parameters? Lot's of APIs have this, but almost all of the time the byte[] is immutable. That's kind of in the same category as what-if String were mutable, no? On Tue, Sep 6, 2016 at 2:11 PM, Julian Hyde wrote: > How bad would it be for API

Re: New committers

Thanks! Will do! -Minji On 9/6/16 1:59 PM, Julian Hyde wrote: MinJi and Francis, You should both now have commit rights. Calcite is a small project, so the process is not rigid. The basic procedure is “use your discretion”. We trust you. Obviously, you should always run the test suite

Re: Dropping support for Guava versions earlier than 14

What is so bad about declaring that variable as a List and making it an ImmutableList underneath? Guard it in the programmer's mind by comments and naming. And if they don't believe you, it still can't be changed. This avoids Guava leakage in the API and still gives you (nearly) all of the

New committers

MinJi and Francis, You should both now have commit rights. Calcite is a small project, so the process is not rigid. The basic procedure is “use your discretion”. We trust you. Obviously, you should always run the test suite before committing. If your change is minor, you can commit without

Re: Dropping support for Guava versions earlier than 14

How bad would it be for API designers and users if java.lang.String were mutable? I would say really, really bad. You could add a lot of comments to the API documentation, but you’d never really be sure that everyone was adhering to the contract. > On Sep 6, 2016, at 1:59 PM, Ted Dunning

Re: solr-sql: adapter for solr cloud

This mailing list is the perfect place to discuss this. (For future reference, for issues we use Apache JIRA[1], not github issues.) We’d be happy to add a mention of your adapter to the site. It could go into the Adapters page[2]. Edit the source of that page[3] and create a pull request.

Re: solr-sql: adapter for solr cloud

That's great! Thank you very much! Best regards, Zhihong SHEN ——— Zhihong SHEN, Ph. D., Senior Engineer Big Data Application Service Technology Laboratory, Computer Network Information Center, Chinese Academy of Sciences office phone:+86-10-58812516 mobile：+86-13671116520 在

Re: Simple Streaming Senario

I have imported as external jars calcite-example-csv, calcite-core, avatica , linq4j, avatica-metrics, avatica-standalone with all their sources and tests, and I get: Exception in thread "main" java.lang.AbstractMethodError:

Re: [ANNOUNCE] New committer: MinJi Kim

Congrats Minji! On Sun, Sep 4, 2016 at 11:42 PM, MinJi Kim wrote: > Thank you for the kind introduction, Julian! Also, thank you everybody > for inviting me to the team! I am looking forward to working with you all > and learning more about Calcite! > > Just a quick

Re: Simple Streaming Senario

That still sounds like a version mismatch. Note that avatica releases are separate from calcite these days. Therefore calcite-core-1.9.0-SNAPSHOT, for instance, depends upon avatica-metrics-1.8.0. I think you should use 1.9.0-SNAPSHOT versions of calcite- jars, and 1.8.0 versions of avatica-

Re: Dropping support for Guava versions earlier than 14

Calcite’s API has a large surface area. The API consists not just of method calls, but also data objects. For example, the Project class [1] represents a project node in a relational algebra expression. Its main field is “public final ImmutableList exps”. It is very important that everyone,

Re: [ANNOUNCE] New committer: MinJi Kim

Congrats and welcome, MinJi! MinJi Kim wrote: Thank you for the kind introduction, Julian! Also, thank you everybody for inviting me to the team! I am looking forward to working with you all and learning more about Calcite! Just a quick introduction: I am an engineer at Dremio, working on a

Re: Dropping support for Guava versions earlier than 14

What is so bad about Guava? I have always found it to be a high quality library. I hear that they have broken backwards compatibility on one or two occasions, but I’ve never been affected by that personally. > On Sep 6, 2016, at 12:04 PM, Andrew Purtell wrote: > > No

Re: Dropping support for Guava versions earlier than 14

The main reason why we don't shade protobuf is MR jobs for bulk load. We are using hbase-protocol in the classpath and clash between shaded and unshaded protobufs happen. Actually I'm not sure whether we still need this (I mean hbase-protocol in the classpath). Actually shading doesn't work well

Re: Dropping support for Guava versions earlier than 14

(from the peanut gallery) I have no strong opinions but find myself presently leaning towards Ted's suggestions. Ideally, I think that we should not expose things in a "public API" which we do not have the ability to guarantee compatibility of. A round-about way of saying "Calcite public

Why varchar columns in where FILTER are transformed to 'CAST($1):....'?

Hi, all I wrote a custom ScannableTable and override the scan(context, filters) method to implement the searching function. When I sent a SQL command like select * from PERSONS where NAME=‘bluejoe’ and AGE>30 In the filters parameter, I found the filter on column `AGE` is parsed properly like

Re: Dropping support for Guava versions earlier than 14

I've been bitten three times: once by CacheBuilder, once by Stopwatch, once by Service. > On Sep 6, 2016, at 12:10 PM, Julian Hyde wrote: > > What is so bad about Guava? I have always found it to be a high quality > library. I hear that they have broken backwards

Re: Dropping support for Guava versions earlier than 14

We were bit by guava comparator chain wrt to booleans. On Tuesday, September 6, 2016, Andrew Purtell wrote: > I've been bitten three times: once by CacheBuilder, once by Stopwatch, > once by Service. > > > On Sep 6, 2016, at 12:10 PM, Julian Hyde