Re: lex parameter does not get taken into account for views
Filed a JIRA: https://issues.apache.org/jira/browse/CALCITE-3549
Danny Chan 于2019年12月2日周一 上午9:06写道：
> Dear Erin ~
>
> You are right, Calcite now always hard code the parser config for JDBC
> query[1], that means, Lex config for view expanding is not supported yet,
> can you log a issue and probably fire a patch to support that?
>
> [1]
> https://github.com/apache/calcite/blob/ab136b5f76a4cb951e847fcba6b414c5e80dbbe6/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L385
>
> Best,
> Danny Chan
> 在 2019年12月2日 +0800 AM4:19，Erin Drummond ，写道：
> > Hello,
> >
> > I am currently attempting to test out the views feature of Calcite.
> >
> > I am using a connection string like so:
> > jdbc:calcite:lex=JAVA;model=inline:
> >
> > I have created a JdbcSchema that is attached to an actual database - lets
> > call it "t1". I can successfully run the query "select * from t1.table
> > limit 10"
> >
> > I then created another schema, defined like so:
> > {
> > "name": "viewtest",
> > "tables": [
> > { "name": "test_view", "type": "view", "sql": "select * from
> > t1.table limit 10" }
> > ]
> > }
> >
> > The idea is to set up connections to a bunch of physical data sources and
> > then have a "views" schema that just contains views over them.
> >
> > However, when attempting to run the query "select * from
> > viewtest.test_view", I get the following exception:
> >
> > StatementCallback; uncategorized SQLException for SQL [select * from
> > viewtest.test_view]; SQL state [null]; error code [0];
> > Error while executing SQL \"select * from viewtest.test_view\": From line
> > 1, column 15 to line 1, column 32: Object 'T1' not found; did you mean
> 't1'?
> >
> > I can clearly see that lex=JAVA is not being used for the view and the
> > default lex=ORACLE is being used. If I change the view SQL to 'select *
> > from "t1".table limit 10' it works - but I don't want to have to quote
> the
> > identifiers oracle style, I would like the lex=JAVA that I specified on
> the
> > connection string to flow down to views as well.
> >
> > What am I missing here?
> >
> > Cheers,
> > Erin
>
[jira] [Created] (CALCITE-3549) Lex config for view expanding is not supported
Jin Xing created CALCITE-3549:
-
Summary: Lex config for view expanding is not supported
Key: CALCITE-3549
URL: https://issues.apache.org/jira/browse/CALCITE-3549
Project: Calcite
Issue Type: Improvement
Reporter: Jin Xing
UT as below:
{code:java}
// JdbcTest.java
@Test public void testDEV() {
modelWithView("select * from EMPLOYEES where deptno = 10", null)
.with(Lex.JAVA)
.query("select * from adhoc.V order by name desc")
.returns("");
}
{code}
Failed with
{code:java}
org.apache.calcite.sql.validate.SqlValidatorException: Column 'DEPTNO' not
found in any table; did you mean 'deptno'?
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: lex parameter does not get taken into account for views
Dear Erin ~
You are right, Calcite now always hard code the parser config for JDBC
query[1], that means, Lex config for view expanding is not supported yet, can
you log a issue and probably fire a patch to support that?
[1]
https://github.com/apache/calcite/blob/ab136b5f76a4cb951e847fcba6b414c5e80dbbe6/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L385
Best,
Danny Chan
在 2019年12月2日 +0800 AM4:19，Erin Drummond ，写道：
> Hello,
>
> I am currently attempting to test out the views feature of Calcite.
>
> I am using a connection string like so:
> jdbc:calcite:lex=JAVA;model=inline:
>
> I have created a JdbcSchema that is attached to an actual database - lets
> call it "t1". I can successfully run the query "select * from t1.table
> limit 10"
>
> I then created another schema, defined like so:
> {
> "name": "viewtest",
> "tables": [
> { "name": "test_view", "type": "view", "sql": "select * from
> t1.table limit 10" }
> ]
> }
>
> The idea is to set up connections to a bunch of physical data sources and
> then have a "views" schema that just contains views over them.
>
> However, when attempting to run the query "select * from
> viewtest.test_view", I get the following exception:
>
> StatementCallback; uncategorized SQLException for SQL [select * from
> viewtest.test_view]; SQL state [null]; error code [0];
> Error while executing SQL \"select * from viewtest.test_view\": From line
> 1, column 15 to line 1, column 32: Object 'T1' not found; did you mean 't1'?
>
> I can clearly see that lex=JAVA is not being used for the view and the
> default lex=ORACLE is being used. If I change the view SQL to 'select *
> from "t1".table limit 10' it works - but I don't want to have to quote the
> identifiers oracle style, I would like the lex=JAVA that I specified on the
> connection string to flow down to views as well.
>
> What am I missing here?
>
> Cheers,
> Erin
Re: [DISCUSS] Towards Avatica 1.16.0
The Avatica 1.16.0 release seems to be a bit overdue. I plan to make rc0 available for voting on Friday morning (the 6th of December) Australian Eastern Standard time (probably Thursday in some parts of Europe and America). If there are any changes you would like to see in this release, please try to get them in. If committers could review and merge some of the open PRs[1], that would be highly appreciated too! If the proposed time frame does not work for you, please let me know. Francis [1] https://github.com/apache/calcite-avatica/pulls On 10/10/2019 10:26 am, Francis Chuang wrote: Hey everyone, It's been around 5 months since the last Avatica release. There's been a couple of commits to the code-base since and I'd like to use this as an opportunity to get a few more PRs in and make a release available for voting. I am happy to be release manager for this release. In terms of PRs I am hoping for the following to be merged for this release: - CALCITE-3384: Support Kerberos using SPNEGO over HTTPS - https://github.com/apache/calcite-avatica/pull/113 (Josh is reviewing) - CALCITE-333: Add pluggable frame size limits - https://issues.apache.org/jira/browse/CALCITE- (looking for a reviewer) - CALCITE-3199: Fix unixDateCeil and unixDateFloor - https://github.com/apache/calcite-avatica/pull/109 (looking for a reviewer) - CALCITE-3162: Reading arrays from Calcite through JdbcMeta throws exception - https://github.com/apache/calcite-avatica/pull/106 (looking for a reviewer) - CALCITE-3163: Mapping types in AbstractCursor does not adhere to JDBC spec - https://github.com/apache/calcite-avatica/pull/105 (looking for a reviewer) - CALCITE-3158: Move build system to Gradle - https://github.com/apache/calcite-avatica/pull/104 (Vladimir has put a lot of effort into this. Can we get some consensus as to whether this should to be merged?) - CALCITE-3078: Duplicate code for lastDay in Calcite and Avatica - https://github.com/apache/calcite-avatica/pull/98 (looking for a reviewer) - No Jira: Support UNIX timestamp to string date - https://github.com/apache/calcite-avatica/pull/96 (can someone confirm if these changes are valid or should the PR be closed?) - CALCITE-2704: Avoid using ISO-8859-1 to parse request in JSONHandler - https://github.com/apache/calcite-avatica/pull/85 (Someone posted some tests in the issue comments. Can someone please add the tests, review and merge?) - CALCITE-1806: Add Spark JDBC tests - https://github.com/apache/calcite-avatica/pull/28 (Kevin, any chance you can take another look at this?) If you have some spare cycles for Avatica, please pick up some of the PRs in this list, it would be very much appreciated! Francis
lex parameter does not get taken into account for views
Hello,
I am currently attempting to test out the views feature of Calcite.
I am using a connection string like so:
jdbc:calcite:lex=JAVA;model=inline:
I have created a JdbcSchema that is attached to an actual database - lets
call it "t1". I can successfully run the query "select * from t1.table
limit 10"
I then created another schema, defined like so:
{
"name": "viewtest",
"tables": [
{ "name": "test_view", "type": "view", "sql": "select * from
t1.table limit 10" }
]
}
The idea is to set up connections to a bunch of physical data sources and
then have a "views" schema that just contains views over them.
However, when attempting to run the query "select * from
viewtest.test_view", I get the following exception:
StatementCallback; uncategorized SQLException for SQL [select * from
viewtest.test_view]; SQL state [null]; error code [0];
Error while executing SQL \"select * from viewtest.test_view\": From line
1, column 15 to line 1, column 32: Object 'T1' not found; did you mean 't1'?
I can clearly see that lex=JAVA is not being used for the view and the
default lex=ORACLE is being used. If I change the view SQL to 'select *
from "t1".table limit 10' it works - but I don't want to have to quote the
identifiers oracle style, I would like the lex=JAVA that I specified on the
connection string to flow down to views as well.
What am I missing here?
Cheers,
Erin
Re: JProfiler license for committers
I find Java Flight Recorder and async-profiler to be good enough. Both tools are free to use, they both can be used to profile production systems, and they both produce actionable results. Stamatis, Andrei, have you considered JFR / async-profiler? Even though I do not object asking for a license, I do not feel comfortable promoting third-party profilers if it turns out nobody uses the license. AFAIK IntelliJ IDEA 2019.2+ has integration with both JFR and async-profiler (see https://www.jetbrains.com/help/idea/cpu-profiler.html ), however, I have not used it, and I happen to use the tools directly. Vladimir
Re: JProfiler license for committers
I was also thinking getting open-source license for one of the profiling tools. I'm more familiar with YourKit but if JProfiler is comparable then don't have any preference. On Sat, Nov 30, 2019 at 1:57 AM Danny Chan wrote: > Personally I did not use JProfiler pretty much often, but adding the link > to the page may give some help. > > Best, > Danny Chan > 在 2019年11月30日 +0800 AM4:50，Stamatis Zampetakis ，写道： > > Hello, > > > > It seems that we can obtain a free license [1] for a certain number of > > committers in exchange for a link to their product on our website. > > > > Personally, I am not a casual user of JProfiler but I happen to need it > > from time to time and it would be more convenient to have a license for > it. > > > > Is anybody else interested in a JProfiler license? > > > > How do you feel about adding a link in our website (possibly in develop > > section)? > > > > Best, > > Stamatis > > > > [1] https://www.ej-technologies.com/buy/jprofiler/openSource/enter >
