[jira] [Created] (CALCITE-1526) Use Strong to infer whether a predicate's inputs may be null

[Julian Hyde (JIRA)]

Julian Hyde created CALCITE-1526:


 Summary: Use Strong to infer whether a predicate's inputs may be 
null
 Key: CALCITE-1526
 URL: https://issues.apache.org/jira/browse/CALCITE-1526
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde


{{RexImplicationChecker}} must use 
[Strong|https://calcite.apache.org/apidocs/org/apache/calcite/plan/Strong.html] 
to infer whether a predicate's inputs may be null. In particular the code in 
{{RexImplicationChecker.implies2}}.

Also {{RelMdPredicates.projectPredicate}}.

[~jcamachorodriguez], Could/should {{RexUtil.ExprSimplifier}} be using 
{{Strong}}?

Also, maybe, {{RexUtil.simplifyIs}}.

Also, {{LogicVisitor}} might be able to deduce that an expression is never null 
if certain input fields are not null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Embedding Calcite, adjusting convertlets

[Julian Hyde]

Can you please add (1) and (2) to 
https://issues.apache.org/jira/browse/CALCITE-1525 
, which deals with the 
whole issue of using “Planner” within the JDBC driver, so we can be consistent.

(3) doesn’t look likely to be related. Do your queries have UNION or other 
set-ops? Are you sorting on columns that do not appear in the final result?

Julian


> On Nov 28, 2016, at 10:45 AM, Gian Merlino  wrote:
> 
> I traveled a bit down the Frameworks/Planner road and got most of my tests
> passing, but ran into some problems getting them all to work:
> 
> (1) "EXPLAIN PLAN FOR" throws NullPointerException during Planner.validate.
> It looks like CalcitePrepareImpl has some special code to handle validation
> of EXPLAIN, but PlannerImpl doesn't. I'm not sure if this is something I
> should be doing on my end, or if it's a bug in PlannerImpl.
> (2) I don't see a way to do ?-style prepared statements with bound
> variables, which _is_ possible with the JDBC driver route.
> (3) Not sure why this is happening, but for some reason ORDER BY / LIMIT
> clauses are getting ignored sometimes, even when they work with the JDBC
> driver route. This may be something messed up with my rules though and may
> not be Calcite's fault.
> 
> Julian, do any of these look like bugs that should be raised in jira, or
> are they just stuff I should be dealing with on my side?
> 
> Btw, I do like that the Frameworks/Planner route gives me back the RelNode
> itself, since that means I can make the Druid queries directly without
> needing to go through the extra layers of the JDBC driver. That part is
> nice.
> 
> Gian
> 
> On Wed, Nov 23, 2016 at 10:11 PM, Julian Hyde  wrote:
> 
>> I don’t know how it’s used outside Calcite. Maybe some others can chime in.
>> 
>> Thanks for the PR. I logged https://issues.apache.org/jira
>> /browse/CALCITE-1509 
>> for it, and will commit shortly.
>> 
>> Julian
>> 
>>> On Nov 23, 2016, at 12:32 PM, Gian Merlino  wrote:
>>> 
>>> Do you know examples of projects that use Planner or PlannerImpl
>> currently
>>> (from "outside")? As far as I can tell, within Calcite itself it's only
>>> used in test code. Maybe that'd be a better entry point.
>>> 
>>> In the meantime I raised a PR here for allowing a convertlet table
>> override
>>> in a CalcitePrepareImpl: https://github.com/apache/calcite/pull/330.
>> That
>>> was enough to get the JDBC driver on my end to behave how I want it to.
>>> 
>>> Gian
>>> 
>>> On Thu, Nov 17, 2016 at 5:23 PM, Julian Hyde  wrote:
>>> 
 I was wrong earlier… FrameworkConfig already has a getConvertletTable
 method. But regarding using FrameworkConfig from within the JDBC driver,
 It’s complicated. FrameworkConfig only works if you are “outside”
>> Calcite,
 whereas CalcitePrepare is when you are customizing from the inside, and
 sadly CalcitePrepare does not use a FrameworkConfig.
 
 Compare and contrast:
 * CalcitePrepareImpl.getSqlToRelConverter [ https://github.com/apache/
 calcite/blob/3f92157d5742dd10f3b828d22d7a753e0a2899cc/core/
>> src/main/java/
 org/apache/calcite/prepare/CalcitePrepareImpl.java#L1114 <
 https://github.com/apache/calcite/blob/3f92157d5742dd10f3b828d22d7a75
 3e0a2899cc/core/src/main/java/org/apache/calcite/prepare/
 CalcitePrepareImpl.java#L1114> ]
 * PlannerImpl.rel [ https://github.com/apache/calcite/blob/
 105bba1f83cd9631e8e1211d262e4886a4a863b7/core/src/main/java/
 org/apache/calcite/prepare/PlannerImpl.java#L225 <
 https://github.com/apache/calcite/blob/105bba1f83cd9631e8e1211d262e48
 86a4a863b7/core/src/main/java/org/apache/calcite/prepare/
 PlannerImpl.java#L225> ]
 
 The latter uses a convertletTable sourced from a FrameworkConfig.
 
 The ideal thing would be to get CalcitePrepareImpl to use a PlannerImpl
>> to
 do its dirty work. Then “inside” and “outside” would work the same.
>> Would
 definitely appreciate that as a patch.
 
 If you choose to go the JDBC driver route, you could override
 Driver.createPrepareFactory to produce a sub-class of CalcitePrepare
>> that
 works for your environment, one with an explicit convertletTable rather
 than just using the default.
 
 Julian
 
 
> On Nov 17, 2016, at 5:01 PM, Gian Merlino  wrote:
> 
> Hey Julian,
> 
> If the convertlets were customizable with a FrameworkConfig, how would
>> I
> use that configure the JDBC driver (given that I'm doing it with the
>> code
> upthread)? Or would that suggest using a different approach to
>> embedding
> Calcite?
> 
> Gian
> 
> On Thu, Nov 17, 2016 at 4:02 PM, Julian Hyde  wrote:
> 
>> Convertlets have a similar effect to planner rules (albeit they act on
>> scalar expressions, 

[jira] [Created] (CALCITE-1525) Use "Planner" to handle query preparation process in CalcitePrepareImpl

[Julian Hyde (JIRA)]

Julian Hyde created CALCITE-1525:


 Summary: Use "Planner" to handle query preparation process in 
CalcitePrepareImpl
 Key: CALCITE-1525
 URL: https://issues.apache.org/jira/browse/CALCITE-1525
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde


The query preparation process (parse, validate, convert SqlNode to RelNode, 
plan) is complicated, and each step depends on state on the previous one. We 
have two ways of managing that preparation process: 
[CalcitePrepareImpl|https://calcite.apache.org/apidocs/org/apache/calcite/prepare/CalcitePrepareImpl.html]
 (used by the JDBC driver) and 
[org.apache.calcite.tools.Planner|https://calcite.apache.org/apidocs/org/apache/calcite/tools/Planner.html]
 (your only practical option if your code doesn't live inside JDBC).

We should make {{CalcitePrepareImpl}} use a {{Planner}} internally, get rid of 
shared logic, and make them behave consistently.

>From [email 
>thread|https://mail-archives.apache.org/mod_mbox/calcite-dev/201611.mbox/%3C9499388B-64A4-4BB0-9957-7FABC913AA48%40apache.org%3E]
> with [~gian]:

{quote}
Compare and contrast:
 * 
[CalcitePrepareImpl.getSqlToRelConverter|https://github.com/apache/calcite/blob/3f92157d5742dd10f3b828d22d7a753e0a2899cc/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L1114]
 * 
[PlannerImpl.rel|https://github.com/apache/calcite/blob/105bba1f83cd9631e8e1211d262e4886a4a863b7/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L225]
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)