[GitHub] calcite-avatica-go pull request #6: Bump gokrb5 client to v2

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] calcite-avatica-go pull request #6: Bump gokrb5 client to v2

[F21]

GitHub user F21 opened a pull request:

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

Bump gokrb5 client to v2



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

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

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

https://github.com/apache/calcite-avatica-go/pull/6.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 #6


commit 4d019103b9efb92e0039f9c1b79d7497b551e14b
Author: Francis Chuang 
Date:   2017-11-18T23:01:28Z

Bump gokrb5 client to v2




---

Re: Setting connection's auto-commit property from the configuration files?

[Julian Hyde]

We should make autoCommit a connection property (see 
https://calcite.apache.org/docs/adapter.html#jdbc-connect-string-parameters 
). 
Also any other properties set via methods in java.sql.Connection; and also 
things in java.sql.Statement such as fetchSize.

We should add them to Avatica (see 
https://calcite.apache.org/avatica/apidocs/org/apache/calcite/avatica/BuiltInConnectionProperty.html
 
)
 and they will be available for Calcite. 

Julian


> On Nov 18, 2017, at 3:15 AM, Christian Tzolov  wrote:
> 
> Is there a way to set the ConnectionProperties#setAutoCommit(boolean val)
> from the model.json or perhaps via the jdbc URL attributes?
> 
> E.g. i'm looking for any configuration option that wouldn't require writing
> code such as Connection.setAutoCommit(...)
> 
> -- 
> Christian Tzolov  | Principle Software
> Engineer | Pivotal  | ctzo...@pivotal.io |+31610285517

Setting connection's auto-commit property from the configuration files?

[Christian Tzolov]

Is there a way to set the ConnectionProperties#setAutoCommit(boolean val)
from the model.json or perhaps via the jdbc URL attributes?

E.g. i'm looking for any configuration option that wouldn't require writing
code such as Connection.setAutoCommit(...)

-- 
Christian Tzolov  | Principle Software
Engineer | Pivotal  | ctzo...@pivotal.io |+31610285517

Re: BindableTableScan is losing aliased named

[Enrico Olivelli]

I solved my problem just by capturing the original rowtype after sql parser.
Thanks
Enrico

Il ven 17 nov 2017, 22:44 Enrico Olivelli  ha scritto:

>
>
> Il ven 17 nov 2017, 22:36 Julian Hyde  ha scritto:
>
>> Translating to RelNode loses some metadata. When preparing a SQL
>> statement, we use the column names and types given to us by the
>> validator for use by ResultSetMetaData.
>>
>> There's a related interesting case where a column appears in ORDER BY
>> but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The
>> RelNode needs to have 2 columns but the ResultSet thinks it only has
>> one.
>>
>
> I am observing that Calcite tends to add support fields always at the
> 'right'. Is this a general behaviour or I am lucky and all the plans I am
> seeing behave this way ?
>
> I think I will try to capture field names from the SqlNodes, but this will
> be feasible if and only if the first N selected RelNodes of the physical
> plan represent the first N SqlNodes in the Select clause
>
> Enrico
>
>
>> Julian
>>
>>
>> On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli 
>> wrote:
>> > Il ven 17 nov 2017, 19:19 Julian Hyde  ha scritto:
>> >
>> >> > IMHO It would better to keep somethin like an EnumerableProjection
>> which
>> >> > renames the fields
>> >>
>> >> I disagree. If we commit to preserving field names all kinds of
>> >> optimization are not possible.
>> >>
>> >> In Calcite RelNode world, field names are a hint to make debugging
>> >> easier but are not ultimately reliable. The reliable way to reference
>> >> fields is by position.
>> >>
>> >
>> >
>> > I understand your point Julian. In my case I want the final resultset to
>> > have knowledge of the alias requested by the user.
>> >
>> > Select a as b from table
>> >
>> > ResultSet rs = ...
>> > String col = rs.getString("b");
>> > If I am losing the alias I can't support this case.
>> > The test case from Luis is working so there is some trick I am missing
>> >
>> > Enrico
>> >
>> >
>> >> Julian
>> >>
>> >>
>> >> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli 
>> >> wrote:
>> >> > I run the debugger on your test case.
>> >> > IMHO The BindableTableScan RelNode does not keep the original
>> aliases of
>> >> > the query.
>> >> > The test cases runs CalciteConnection, maybe there is some magic
>> during
>> >> the
>> >> > execution of the query.
>> >> > Can you provide me some insight ?
>> >> > Maybe it is better that I provide a reproducer.
>> >> > I am not using CalciteConnection but only the planner
>> >> >
>> >> > Thanks
>> >> > Enrico
>> >> >
>> >> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli :
>> >> >
>> >> >> your test is working
>> >> >>
>> >> >> I will try to understand where is the problem in my code
>> >> >>
>> >> >> b.q. I am looking for a sponsor for this patch, which is a real
>> blocker
>> >> >> for me, could you pleas take a look Luis ?
>> >> >> https://github.com/apache/calcite/pull/568
>> >> >>
>> >> >> Thank you
>> >> >> Enrico
>> >> >>
>> >> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
>> >> >> lfka...@yahoo.com.br.invalid>:
>> >> >>
>> >> >>> Please insert the following test in ScannableTableTest and run:
>> >> >>>/** ProjectableFilterableTable project push down using alias. */
>> >> >>>   @Test public void testPFPushDownWithAlias() throws Exception {
>> >> >>> final StringBuilder buf = new StringBuilder();
>> >> >>> final Table table = new BeatlesProjectableFilterableTable(buf,
>> >> true);
>> >> >>> CalciteAssert.that()
>> >> >>> .with(newSchema("s", "beatles", table))
>> >> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>> >> >>> .explainContains("EnumerableInterpreter\n"
>> >> >>> + "  BindableTableScan(table=[[s, beatles]],
>> >> >>> projects=[[0]])\n")
>> >> >>> .returnsUnordered("THEKEY=4",
>> >> >>> "THEKEY=4",
>> >> >>> "THEKEY=6",
>> >> >>> "THEKEY=5");  }
>> >> >>> It passes for me.
>> >> >>> You'll need the updated version of this test class, because it was
>> >> >>> recently refactored.
>> >> >>> It's usually easier for other people to test the problem if you
>> create
>> >> >>> runnable test cases to show the problem.   Em sexta-feira, 17 de
>> >> novembro
>> >> >>> de 2017 14:29:09 BRST, Enrico Olivelli 
>> escreveu:
>> >> >>>
>> >> >>>  In the RowType I have 'k1' and not "thekey"
>> >> >>>
>> >> >>> Enrico
>> >> >>>
>> >> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
>> >> >>> > >> >>> >:
>> >> >>>
>> >> >>> >  Did you execute the query?
>> >> >>> > ProjectRemoveRule removes the Project when it is "trivial".
>> Since
>> >> the
>> >> >>> > only used project was pushed to BindableTableScan, the Project
>> would
>> >> >>> only
>> >> >>> > set the alias, but that can be done in row type.
>> >> >>> > The result is correct 

Another error on using unbounded dynamic parameters

[Enrico Olivelli]

I found another query sent to my DBMS which causes troubles to Calcite

SELECT ? as foo, k1, n1 FROM mytable

The result is the usual: "Illegal use of dynamic parameter"

This time it is impossible to infer the type of the parameter.
I wonder if it would be possible to implement a configuration flag to make
the validator more "lenient" and allow unknowntype for dyn parameters

I think I am near the end of my transition to Calcite, this is the major
obstacle, I am seeing this fo updates, some kind of inserts and for this
kind of queries


Thoughts ?

Thank you very much, I like Calcite and I hope to be in production soon

Enrico


stacktrace:

org.apache.calcite.runtime.CalciteContextException: At line 1, column 8:
Illegal use of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4655)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1698)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1773)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:461)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:3958)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3219)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:949)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:930)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:226)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:905)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:615)
at org.apa