Re: [CANCEL] [VOTE] Release apache-calcite-1.23.0 (release candidate 0)

[Stamatis Zampetakis]

Did you fill your PGP key fingerprint in https://id.apache.org/ ?

This step is necessary in order to see your key under
https://people.apache.org/keys/committer/

Best,
Stamatis

On Thu, May 14, 2020 at 3:25 AM Haisheng Yuan  wrote:

> Thanks a lot.
> I will try it again.
>
> On 2020/05/14 01:03:03, Francis Chuang  wrote:
> > Another thing I'd suggest is to upload the key to the default server
> > used by GPG and the MIT server.
> > See the last part here:
> >
> https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84#having-the-owner-of-the-signed-key-upload-the-key-himself
> >
> > On 14/05/2020 10:48 am, Haisheng Yuan wrote:
> > > Hi,
> > >
> > > 24 hours passed, but my key link still doesn't work:
> > > https://people.apache.org/keys/committer/hyuan.asc
> > >
> > > The following link shows key not found (my id is hyuan):
> > > https://people.apache.org/keys/committer/
> > >
> > > But the key is already on key server:
> > >
> http://keyserver.ubuntu.com:11371/pks/lookup?search=0x3CD22ABAC50DDCEF&fingerprint=on&op=index
> > >
> > > Does anyone know what I may miss?
> > >
> > > Thanks
> > > Haisheng Yuan
> > >
> > > On 2020/05/13 07:35:35, Ruben Q L  wrote:
> > >> Hello,
> > >>
> > >> FYI (even though the vote for RC0 is cancelled):
> > >> - Local Calcite build with tests (Windows10 + JDK8): OK
> > >> - Calcite-based application test suite: OK
> > >>
> > >> Best regards,
> > >> Ruben
> > >>
> > >>
> > >> Le mer. 13 mai 2020 à 01:11, Stamatis Zampetakis 
> a
> > >> écrit :
> > >>
> > >>> Hello,
> > >>>
> > >>> The warning basically says that Rui hasn't signed Haisheng's key so
> I guess
> > >>> it is normal.
> > >>>
> > >>> Best,
> > >>> Stamatis
> > >>>
> > >>> On Wed, May 13, 2020 at 12:48 AM Haisheng Yuan 
> wrote:
> > >>>
> >  Hi Rui,
> > 
> >  Thanks for verifying. apache.org will sync hyuan.asc once a day.
> So that
> >  should be available in a few hours.
> >  Regarding the warning, need to investigate what went wrong.
> > 
> >  Thanks,
> >  Haisheng
> > 
> >  On 2020/05/12 22:05:47, Rui Wang  wrote:
> > > Found something that is worth mentioning in this candidate:
> > >
> > > 1. hyuan.asc [1] is not found on the server. Maybe the step that
> login
> > > Apache account [2] and filled out the public key fingerprint didn't
> >  finish?
> > > 2. Verify the artifact by "gpg --verify
> > > apache-calcite-1.23.0-src.tar.gz.asc
> apache-calcite-1.23.0-src.tar.gz"
> >  but
> > > got the following warning:
> > >
> > > gpg: Signature made Mon May 11 21:20:56 2020 PDT
> > >
> > > gpg:using RSA key
> >  ECA9CF33AF2CEC28F3B66A5C3CD22ABAC50DDCEF
> > >
> > > gpg: Good signature from "Haisheng Yuan "
> [unknown]
> > >
> > > gpg: WARNING: This key is not certified with a trusted signature!
> > >
> > > gpg:  There is no indication that the signature belongs to
> the
> > > owner.
> > >
> > > Primary key fingerprint: ECA9 CF33 AF2C EC28 F3B6  6A5C 3CD2 2ABA
> C50D
> >  DCEF
> > >
> > >
> > > [1]: https://people.apache.org/keys/committer/hyuan.asc
> > > [2]: https://id.apache.org
> > >
> > > -Rui
> > >
> > >
> > > On Tue, May 12, 2020 at 10:53 AM Julian Hyde 
> wrote:
> > >
> > >> Even though the vote is canceled, everyone please continue to
> test on
> >  RC0
> > >> (until an RC1 is available). The earlier you find and report
> issues,
> >  the
> > >> sooner we get to a good release.
> > >>
> > >>
> > >>> On May 12, 2020, at 6:11 AM, Haisheng Yuan 
> > >>> wrote:
> > >>>
> > >>> The vote for Apache Calcite 1.23.0 release candidate 0 has beed
> > >> cancelled due to regression.
> > >>>
> > >>> We will fix this and make rc1 available for voting.
> > >>>
> > >>> Best,
> > >>> Haisheng Yuan
> > >>
> > >>
> > >
> > 
> > >>>
> > >>
> >
>

Apache calcite / jdbc Oracle

[Thierry Rolland]

Hello all,


I'm trying calcite avatica v1.16.0 which seems to be a very great tool.

I tried with a postgresql database and that works very fine (I used the 
provided docker standalone server for my tests)



Now, I'm trying with an oracle database (v19c) and like for postgresql, 
I'm using a docker standalone server.


I'm running on an openJDK11 and I have a problem related to the Oracle 
jdbc driver (ojdbc10.jar) which throws an SQLException if the input 
parameter of the method */isWrapperFor/* is not a java interface :



java.lang.RuntimeException: java.sql.SQLException: Object does not wrap 
anything with requested interface
    at 
org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:700)
    at 
org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:726)
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:195)
    at 
org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1215)
    at 
org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1186)
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
    at 
org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:52)
    at 
org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:129)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.Server.handle(Server.java:502)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
    at 
org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)

    at java.lang.Thread.run(Thread.java:748)
*Caused by: java.sql.SQLException: Object does not wrap anything with 
requested interface**
**    at 
oracle.jdbc.driver.OracleStatementWrapper.isWrapperFor(OracleStatementWrapper.java:487)**
**    at 
org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:711)*

    ... 22 more



In the corresponding source code of */JdbcMeta.java/*, the input 
parameter of the method /*isWrapperFor* /is the abstract 
class/*AvaticaPreparedStatement* /(which is not a java interface) /:

/


Meta.StatementTypestatementType= null;
if(statement.isWrapperFor(AvaticaPreparedStatement.class)) {
finalAvaticaPreparedStatementavaticaPreparedStatement;




Does someone have an idea how to solve this problem ?

Thank you in advance.

Thierry

Re: [CANCEL] [VOTE] Release apache-calcite-1.23.0 (release candidate 0)

[Haisheng Yuan]

Yes, I did it 4 days ago.

On 2020/05/14 09:18:38, Stamatis Zampetakis  wrote: 
> Did you fill your PGP key fingerprint in https://id.apache.org/ ?
> 
> This step is necessary in order to see your key under
> https://people.apache.org/keys/committer/
> 
> Best,
> Stamatis
> 
> On Thu, May 14, 2020 at 3:25 AM Haisheng Yuan  wrote:
> 
> > Thanks a lot.
> > I will try it again.
> >
> > On 2020/05/14 01:03:03, Francis Chuang  wrote:
> > > Another thing I'd suggest is to upload the key to the default server
> > > used by GPG and the MIT server.
> > > See the last part here:
> > >
> > https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84#having-the-owner-of-the-signed-key-upload-the-key-himself
> > >
> > > On 14/05/2020 10:48 am, Haisheng Yuan wrote:
> > > > Hi,
> > > >
> > > > 24 hours passed, but my key link still doesn't work:
> > > > https://people.apache.org/keys/committer/hyuan.asc
> > > >
> > > > The following link shows key not found (my id is hyuan):
> > > > https://people.apache.org/keys/committer/
> > > >
> > > > But the key is already on key server:
> > > >
> > http://keyserver.ubuntu.com:11371/pks/lookup?search=0x3CD22ABAC50DDCEF&fingerprint=on&op=index
> > > >
> > > > Does anyone know what I may miss?
> > > >
> > > > Thanks
> > > > Haisheng Yuan
> > > >
> > > > On 2020/05/13 07:35:35, Ruben Q L  wrote:
> > > >> Hello,
> > > >>
> > > >> FYI (even though the vote for RC0 is cancelled):
> > > >> - Local Calcite build with tests (Windows10 + JDK8): OK
> > > >> - Calcite-based application test suite: OK
> > > >>
> > > >> Best regards,
> > > >> Ruben
> > > >>
> > > >>
> > > >> Le mer. 13 mai 2020 à 01:11, Stamatis Zampetakis 
> > a
> > > >> écrit :
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> The warning basically says that Rui hasn't signed Haisheng's key so
> > I guess
> > > >>> it is normal.
> > > >>>
> > > >>> Best,
> > > >>> Stamatis
> > > >>>
> > > >>> On Wed, May 13, 2020 at 12:48 AM Haisheng Yuan 
> > wrote:
> > > >>>
> > >  Hi Rui,
> > > 
> > >  Thanks for verifying. apache.org will sync hyuan.asc once a day.
> > So that
> > >  should be available in a few hours.
> > >  Regarding the warning, need to investigate what went wrong.
> > > 
> > >  Thanks,
> > >  Haisheng
> > > 
> > >  On 2020/05/12 22:05:47, Rui Wang  wrote:
> > > > Found something that is worth mentioning in this candidate:
> > > >
> > > > 1. hyuan.asc [1] is not found on the server. Maybe the step that
> > login
> > > > Apache account [2] and filled out the public key fingerprint didn't
> > >  finish?
> > > > 2. Verify the artifact by "gpg --verify
> > > > apache-calcite-1.23.0-src.tar.gz.asc
> > apache-calcite-1.23.0-src.tar.gz"
> > >  but
> > > > got the following warning:
> > > >
> > > > gpg: Signature made Mon May 11 21:20:56 2020 PDT
> > > >
> > > > gpg:using RSA key
> > >  ECA9CF33AF2CEC28F3B66A5C3CD22ABAC50DDCEF
> > > >
> > > > gpg: Good signature from "Haisheng Yuan "
> > [unknown]
> > > >
> > > > gpg: WARNING: This key is not certified with a trusted signature!
> > > >
> > > > gpg:  There is no indication that the signature belongs to
> > the
> > > > owner.
> > > >
> > > > Primary key fingerprint: ECA9 CF33 AF2C EC28 F3B6  6A5C 3CD2 2ABA
> > C50D
> > >  DCEF
> > > >
> > > >
> > > > [1]: https://people.apache.org/keys/committer/hyuan.asc
> > > > [2]: https://id.apache.org
> > > >
> > > > -Rui
> > > >
> > > >
> > > > On Tue, May 12, 2020 at 10:53 AM Julian Hyde 
> > wrote:
> > > >
> > > >> Even though the vote is canceled, everyone please continue to
> > test on
> > >  RC0
> > > >> (until an RC1 is available). The earlier you find and report
> > issues,
> > >  the
> > > >> sooner we get to a good release.
> > > >>
> > > >>
> > > >>> On May 12, 2020, at 6:11 AM, Haisheng Yuan 
> > > >>> wrote:
> > > >>>
> > > >>> The vote for Apache Calcite 1.23.0 release candidate 0 has beed
> > > >> cancelled due to regression.
> > > >>>
> > > >>> We will fix this and make rc1 available for voting.
> > > >>>
> > > >>> Best,
> > > >>> Haisheng Yuan
> > > >>
> > > >>
> > > >
> > > 
> > > >>>
> > > >>
> > >
> >
> 

Re: [DISCUSS] Towards Cascades Optimizer

[Julian Hyde]

> I even added a
> VolcanoPlannerFactory in my code to allow user to specify their own
> planner. But I also see that Julian is more of keeping one planner.

I am fine with multiple planners. (We already have multiple planners -
Hep and Volcano.) Another one or two more is fine.

In the short term (while this development is going on, and until we
build consensus about which planner (or planners) best serves the
community) we will definitely have multiple planners.

But in the long term I don't want to end up with two planners that are
distinct without there being good reason. If it is architecturally
possible, let's make one planner that has the best features of all of
the prototypes.

Also please think carefully about the other places that we can put
"planning" code - the corpus of RelNodes, rules, traits, and metadata.
These systems are orthogonal to planners and if code can be put there,
it becomes available to all planners.

Julian

On Mon, May 11, 2020 at 11:49 PM Jinpeng Wu  wrote:
>
> Hi, Roman.
>
> Your suggestion is good and that's what I thought before. I even added a
> VolcanoPlannerFactory in my code to allow user to specify their own
> planner. But I also see that Julian is more of keeping one planner. This
> has been a long discussion. I think it can hardly goes to a consensus until
> a solution is considered as the best one, which is, as you mentioned,
> fastest, stable and backward compatible. So how about we just move forward,
> making our solution good enough first?
>
> One thing to clarify is that Haisheng and I are actually from the same
> team. It looks like we raised two different solutions, but actually they
> are two different components of a same planner. Haisheng is focusing more
> on trait propagation while I focus on pruning. Even for the conflict, we
> already have many discussions in private and the conclusion is that I will
> find another solution without AC. So Haisheng's interference is not a
> problem for me. As your planner is a brand new one, I think it should not
> be a problem for you, either.
> The differences between Haisheng and me lies in how we contribute those
> efforts to community. Haisheng is confident that he's code is fully
> controllable and the new feature is useful for ordinary volcano procedure.
> So he modified the VolcanoPlanner directly. As for my code, it is
> controllable now. But I am not so confident when trying something
> aggressive in the future.
> Later on, I will value Julian's advice, trying to keep one planner. I agree
> that modifying the VolcanoPlanner directly does not necessary to make it
> unstable or incompatible. It will surely slow me down when I move forward,
> but not impossible. Also, I don't think one planner is the only way to go.
> For example, if the planner has if/else blocks to check flags everywhere,
> it is no better than having another planner and switching between
> implementations by settings.
>
> Thanks,
> Jinpeng
>
> On Tue, May 12, 2020 at 2:16 AM Julian Hyde  wrote:
>
> > If there’s a way for all of these efforts to be committed to master,
> > disabled by default, but such that they can be enabled by setting a flag,
> > then we can at least avoid merge conflicts.
> >
> > I hope that this “trunk-based development” approach is technically
> > feasible. If the rule and metadata APIs are essentially unchanged, and the
> > planner API is evolved smoothly, we should be able to do it.
> >
> > From the perspective of the project and community, this is certainly a
> > good problem to have. An embarrassment of riches.
> >
> > From the perspective of the developers, we should their work as painless
> > as possible. We, the community, also owe it them to make a timely decision
> > about which effort (or efforts) we wish to support long-term.
> >
> > Julian
> >
> >
> > > On May 11, 2020, at 7:04 AM, Roman Kondakov 
> > wrote:
> > >
> > > Hi Jinpeng,
> > >
> > > Apache Calcite community has entered into the interesting situation: we
> > > have several concurrent efforts of building the new Cascades style
> > > optimizers. I can see at least three activities (correct me if I'm
> > wrong):
> > >
> > > 1. Haisheng's gradual rebuilding of VolcanoPlanner [1]
> > > 2. Jinpeng's new CascadesPlanner based on VolcanoPlanner [2]
> > > 3. My brand new CascadesPlanner [3]
> > >
> > > All these activities are independent and may interfere with each other.
> > > It is not good. We still don't know which approach is better and which
> > > optimizer will be the most efficient while keeping backward
> > compatibility.
> > >
> > > In my opinion we must refrain from breaking changes in the master branch
> > > right now because it can break other optimizers.
> > >
> > > I think we need to develop a further strategy for activities related to
> > > the new optimizers:
> > > - find out the way how we will choose the new default Cascades optimizer
> > > for Calcite: it should be stable, fast and backward-compatible
> > > optimizer. If all optimizers wi

Re: Apache calcite / jdbc Oracle

[Julian Hyde]

That sounds like a bug in Avatica. I was not aware that in
'isWrapperFor(Class iface)', 'iface' had to be an interface, and
had assumed the driver would just return 'false'.

Can you please log it?

A solution would be to create an interface in Avatica for
AvaticaPreparedStatement. (It seems that the 'handle' field is the
only thing that we need from it.)

Julian

On Thu, May 14, 2020 at 8:53 AM Thierry Rolland
 wrote:
>
> Hello all,
>
>
> I'm trying calcite avatica v1.16.0 which seems to be a very great tool.
>
> I tried with a postgresql database and that works very fine (I used the
> provided docker standalone server for my tests)
>
>
> Now, I'm trying with an oracle database (v19c) and like for postgresql,
> I'm using a docker standalone server.
>
> I'm running on an openJDK11 and I have a problem related to the Oracle
> jdbc driver (ojdbc10.jar) which throws an SQLException if the input
> parameter of the method */isWrapperFor/* is not a java interface :
>
>
> java.lang.RuntimeException: java.sql.SQLException: Object does not wrap
> anything with requested interface
>  at
> org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:700)
>  at
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:726)
>  at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:195)
>  at
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1215)
>  at
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1186)
>  at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
>  at
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:52)
>  at
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:129)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.Server.handle(Server.java:502)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
>  at
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
>  at java.lang.Thread.run(Thread.java:748)
> *Caused by: java.sql.SQLException: Object does not wrap anything with
> requested interface**
> **at
> oracle.jdbc.driver.OracleStatementWrapper.isWrapperFor(OracleStatementWrapper.java:487)**
> **at
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:711)*
>  ... 22 more
>
>
>
> In the corresponding source code of */JdbcMeta.java/*, the input
> parameter of the method /*isWrapperFor* /is the abstract
> class/*AvaticaPreparedStatement* /(which is not a java interface) /:
> /
>
>
> Meta.StatementTypestatementType= null;
> if(statement.isWrapperFor(AvaticaPreparedStatement.class)) {
> finalAvaticaPreparedStatementavaticaPreparedStatement;
>
>
>
>
> Does someone have an idea how to solve this problem ?
>
> Thank you in advance.
>
> Thierry
>
>
>
>
>
>
>
>

[jira] [Created] (CALCITE-4002) Add security check to make sure TransformationRule doesn't generate PhysicalNode

[Haisheng Yuan (Jira)]

Haisheng Yuan created CALCITE-4002:
--

 Summary: Add security check to make sure TransformationRule 
doesn't generate PhysicalNode
 Key: CALCITE-4002
 URL: https://issues.apache.org/jira/browse/CALCITE-4002
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Haisheng Yuan


Right now, it is not allowed to generate {{PhysicalNode}} in logical 
{{TransformationRule}}, but it is just a contract, not being enforced. Add a 
security check to make sure we throw if a {{PhysicalNode}} is generated in 
{{VolcanoPlanner}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-4003) In MaterializationTest, FilterProjectTransposeRule matches with logical and physical convention

[Haisheng Yuan (Jira)]

Haisheng Yuan created CALCITE-4003:
--

 Summary: In MaterializationTest, FilterProjectTransposeRule 
matches with logical and physical convention
 Key: CALCITE-4003
 URL: https://issues.apache.org/jira/browse/CALCITE-4003
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Haisheng Yuan


In MaterializationTest.testMaterializationSubstitution2, 
FilterProjectTransposeRule matches with logical and physical convention at the 
same time, that means, LogicalFilter and EnumerableProject. We should check and 
prevent this from happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-4004) Override RelOptRuleOperand.toString()

[Haisheng Yuan (Jira)]

Haisheng Yuan created CALCITE-4004:
--

 Summary: Override RelOptRuleOperand.toString()
 Key: CALCITE-4004
 URL: https://issues.apache.org/jira/browse/CALCITE-4004
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Haisheng Yuan


Override RelOptRuleOperand.toString() to facilitate debugging, otherwise, it is 
so tedious...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

bug in DelegatingScope?

[Laurent Goujon]

Hi,

I was looking at the validation code and at some point I saw that piece of
code in DelegatingScope#fullyQualify:
https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/sql/validate/DelegatingScope.java#L309

  for (; i > 0; i--) {
final SqlIdentifier prefix = identifier.getComponent(0, i);
resolved.clear();
resolve(prefix.names, nameMatcher, false, resolved);
if (resolved.count() == 1) {
  final Resolve resolve = resolved.only();
  fromNs = resolve.namespace;
  fromPath = resolve.path;
  fromRowType = resolve.rowType();
  break;
}
// Look for a table alias that is the wrong case.
if (nameMatcher.isCaseSensitive()) {
  final SqlNameMatcher liberalMatcher = SqlNameMatchers.liberal();
  resolved.clear();
  resolve(prefix.names, liberalMatcher, false, resolved);
  if (resolved.count() == 1) {
final Step lastStep = Util.last(resolved.only().path.steps());
throw validator.newValidationError(prefix,
RESOURCE.tableNameNotFoundDidYouMean(prefix.toString(),
lastStep.name));
  }
}
  }

This code looks buggy to me: the check for an alias with the wrong case
should happen after the loop is completed and no prefix has been resolved.
Can someone tell me if I'm correct about it? Unfortunately I was not able
to come up with a test case to demonstrate it.

Re: Apache calcite / jdbc Oracle

[Laurent Goujon]

I checked
https://docs.oracle.com/javase/7/docs/api/java/sql/Wrapper.html#isWrapperFor(java.lang.Class),
and it mentions interface in multiple places, but it doesn't say explicitly
that it should throw if the provided argument is not an interface. And I
guess Oracle driver chose to enforce this strictly by throwing an exception
instead of returning false?



On Thu, May 14, 2020 at 12:31 PM Julian Hyde  wrote:

> That sounds like a bug in Avatica. I was not aware that in
> 'isWrapperFor(Class iface)', 'iface' had to be an interface, and
> had assumed the driver would just return 'false'.
>
> Can you please log it?
>
> A solution would be to create an interface in Avatica for
> AvaticaPreparedStatement. (It seems that the 'handle' field is the
> only thing that we need from it.)
>
> Julian
>
> On Thu, May 14, 2020 at 8:53 AM Thierry Rolland
>  wrote:
> >
> > Hello all,
> >
> >
> > I'm trying calcite avatica v1.16.0 which seems to be a very great tool.
> >
> > I tried with a postgresql database and that works very fine (I used the
> > provided docker standalone server for my tests)
> >
> >
> > Now, I'm trying with an oracle database (v19c) and like for postgresql,
> > I'm using a docker standalone server.
> >
> > I'm running on an openJDK11 and I have a problem related to the Oracle
> > jdbc driver (ojdbc10.jar) which throws an SQLException if the input
> > parameter of the method */isWrapperFor/* is not a java interface :
> >
> >
> > java.lang.RuntimeException: java.sql.SQLException: Object does not wrap
> > anything with requested interface
> >  at
> > org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:700)
> >  at
> > org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:726)
> >  at
> >
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:195)
> >  at
> >
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1215)
> >  at
> >
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1186)
> >  at
> >
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> >  at
> > org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:52)
> >  at
> >
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:129)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.Server.handle(Server.java:502)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> >  at
> >
> org.apache.calcite.avatica.standalone.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> >  at java.lang.Thread.run(Thread.java:748)
> > *Caused by: java.sql.SQLException: Object does not wrap anything with
> > requested interface**
> > **at
> >
> oracle.jdbc.driver.OracleStatementWrapper.isWrapperFor(OracleStatementWrapper.java:487)**
> > **at
> > org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:711)*
> >  ... 22 more
> >
> >
> >
> > In the corresponding source code of */JdbcM

Re: Question of Calcite Dynamic Code Generation Feature

[Albert]

like Haisheng mentioned, it is certainly debuggable, although not as
convenient as plain java code.

my understanding is that, the java code generation is merely a
demonstration of the physical plan implementation.
there are all kinds of ways to implement the logical plan, java code is
merely a `helloworld` of that.  you can see many adapters does that
differently.

On Thu, May 14, 2020 at 2:54 AM 徐泷泽 <15258826...@qq.com> wrote:

> Hi buddies !
> Our team is working on developing a  mulit data source sql engine use
> Calcite.But something confuse us,  why calcite generate Java code
> dynamicly on SQL query, it seen have performance issues in my opinion.
> And building dynamic code object is very hard，the code is unreadable and
> hard to understood, futhermore we can not debug it.
>
>
> i wander why it was designed like that, what advantage  of that .we
> search on internet, 
> but nobody can realy explain it(may be we not goot at search, and poor
> english).
> so anybody can tell me the history of this, or give us some article.
>
>
> applogize for my poor english,  hope you know what i'm taking aboult.
> thank you very very very much !



-- 
~~~
no mistakes
~~